home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Collection of Internet
/
Collection of Internet.iso
/
protocol
/
nbsosi_a.doc
< prev
next >
Wrap
Text File
|
1991-07-10
|
585KB
|
11,779 lines
[ PROTOCOLS:NBSOSI-AGREEMENTS.DOC ] [ 8/88 ]
Computer Science and Technology
NBS Special Publication 500-150
Stable Implementation Agreements for Open Systems Interconnection Protocols
Version 1 Edition 3
December 1987
Based on the Proceedings of the NBS Workshop for Implementors of OSI
U.S. Department of Commerce
C. William Verity, Secretary
National Bureau of Standards
Ernest Ambler, Director
Issued January 1988
Table of Contents
1. GENERAL INFORMATION . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 PURPOSE OF THIS DOCUMENT . . . . . . . . . . . . . . . . . . 1
1.2 PURPOSE OF THE WORKSHOP . . . . . . . . . . . . . . . . . . 1
1.3 WORKSHOP ORGANIZATION . . . . . . . . . . . . . . . . . . . 2
2. SUB NETWORKS . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . 1
2.2 SCOPE AND FIELD OF APPLICATION . . . . . . . . . . . . . . . 1
2.3 STATUS . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2.4 ERRATA . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2.5 LOCAL AREA NETWORKS . . . . . . . . . . . . . . . . . . . . 1
2.5.1 IEEE 802.2 LOGICAL LINK CONTROL . . . . . . . . . 1
2.5.2 IEEE 802.3 CSMA/CD ACCESS METHOD . . . . . . . . . 2
2.5.3 IEEE 802.4 TOKEN BUS ACCESS METHOD . . . . . . . . 3
2.5.4 IEEE 802.5 TOKEN RING ACCESS METHOD . . . . . . . 3
2.6 WIDE AREA NETWORKS . . . . . . . . . . . . . . . . . . . . . 5
2.6.1 CCITT RECOMMENDATION X.25 . . . . . . . . . . . . 5
3. NETWORK LAYER . . . . . . . . . . . . . . . . . . . . . . . . . . 1
3.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . 1
3.2 SCOPE AND FIELD OF APPLICATION . . . . . . . . . . . . . . . 1
3.3 STATUS . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
3.4 ERRATA . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
3.5 CONNECTIONLESS-MODE NETWORK SERVICE (CLNS) . . . . . . . . . 1
3.5.1 Provision of CLNS over Local . . . . . . . . . . . 1
3.5.2 Provision of CLNS over X.25 Subnetworks . . . . . 1
3.5.3 Agreements on Protocols . . . . . . . . . . . . . 2
3.5.3.1 ISO 8473 . . . . . . . . . . . . . . . . . . 2
3.5.3.2 Subnetwork Dependent Convergence Function . . 3
3.6 CONNECTION-MODE NETWORK SERVICE (CONS) . . . . . . . . . . . 3
3.6.1 Mandatory Method of Providing CONS . . . . . . . . 3
3.6.2 Additional Option: Provision of CONS over X.25 1980
Subnetworks . . . . . . . . . . . . . . . . . . . 3
3.6.3 Agreements on Protocols . . . . . . . . . . . . . 4
3.6.3.1 ISO 8878 . . . . . . . . . . . . . . . . . . 4
3.6.3.2 Subnetwork Dependent Convergence Protocol (ISO
8878/Annex A) . . . . . . . . . . . . . . . . 4
3.7 ADDRESSING . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.8 ROUTING . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.8.1 Static Routing . . . . . . . . . . . . . . . . . . 5
3.8.2 End System to Intermediate System . . . . . . . . 5
3.9 MIGRATION CONSIDERATIONS . . . . . . . . . . . . . . . . . . 6
3.9.1 X.25-1980 . . . . . . . . . . . . . . . . . . . . 6
3.10 CONFORMANCE . . . . . . . . . . . . . . . . . . . . . . . . 7
4. TRANSPORT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
4.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . 1
4.2 SCOPE AND FIELD OF APPLICATION . . . . . . . . . . . . . . . 1
4.3 STATUS . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
4.4 ERRATA . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
4.5 TRANSPORT CLASS 4 . . . . . . . . . . . . . . . . . . . . . 1
4.5.1 Transport Class . . . . . . . . . . . . . . . . . 1
4.5.2 Protocol Agreements . . . . . . . . . . . . . . . 1
4.5.2.1 Rules for Negotiation . . . . . . . . . . . . 1
4.5.2.2 Transport Class 4 Service Access Points or
Selectors . . . . . . . . . . . . . . . . . . 3
4.5.2.3 Retransmission Timer . . . . . . . . . . . . 3
4.5.2.4 Keep-Alive Function . . . . . . . . . . . . . 4
4.6 TRANSPORT CLASS 0 . . . . . . . . . . . . . . . . . . . . . 6
4.6.1 Transport Class 0 Overview . . . . . . . . . . . . 6
4.6.2 Protocol Agreements . . . . . . . . . . . . . . . 6
4.6.2.1 Transport Class 0 Service Access Points . . . 7
4.6.3 Rules for Negotiation . . . . . . . . . . . . . . 7
5. UPPER LAYERS . . . . . . . . . . . . . . . . . . . . . . . . . . 1
5.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . 1
5.1.1 References . . . . . . . . . . . . . . . . . . . . 1
5.2 SCOPE AND FIELD OF APPLICATION . . . . . . . . . . . . . . . 1
5.3 STATUS . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
5.4 ERRATA . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
5.4.1 ISO Defect Reports . . . . . . . . . . . . . . . . 2
5.4.2 Session Defects . . . . . . . . . . . . . . . . . 2
5.5 ASSOCIATION CONTROL SERVICE ELEMENT . . . . . . . . . . . . 2
5.5.1 Introduction . . . . . . . . . . . . . . . . . . . 2
5.5.2 Services . . . . . . . . . . . . . . . . . . . . . 3
5.5.2.1 ACSE Services . . . . . . . . . . . . . . . . 3
5.5.2.2 Use of Presentation Layer Services . . . . . 3
5.5.3 Protocol agreements . . . . . . . . . . . . . . . 3
5.5.3.1 Application Context . . . . . . . . . . . . . 3
5.5.3.2 Section Deleted . . . . . . . . . . . . . . . 4
5.5.3.3 AE Title . . . . . . . . . . . . . . . . . . 4
5.6 PRESENTATION . . . . . . . . . . . . . . . . . . . . . . . . 4
5.6.1 Introduction . . . . . . . . . . . . . . . . . . . 4
5.6.2 Services . . . . . . . . . . . . . . . . . . . . . 5
5.6.2.1 Presentation Services . . . . . . . . . . . . 5
5.6.2.2 Use of Session Layer Services . . . . . . . . 6
5.6.3 Protocol Agreements . . . . . . . . . . . . . . . 6
5.6.3.1 Transfer Syntaxes . . . . . . . . . . . . . . 6
5.6.3.2 Abstract Syntaxes . . . . . . . . . . . . . . 6
5.6.3.3 Presentation Context Identifier . . . . . . . 6
5.6.3.4 Mode-selector Position in SET . . . . . . . . 7
5.6.3.5 Default Context . . . . . . . . . . . . . . . 7
5.6.3.6 P-Selectors . . . . . . . . . . . . . . . . . 7
5.6.3.7 Provider Abort Parameters . . . . . . . . . . 7
5.6.3.8 Provider Aborts and Session Version . . . . . 7
5.6.3.9 CPC-type . . . . . . . . . . . . . . . . . . 7
5.6.3.10 Presentation-context-definition-result-list . 8
5.6.3.11 RS-PPDU . . . . . . . . . . . . . . . . . . . 8
5.6.4 Presentation ASN.1 Encoding Rules . . . . . . . . 8
5.6.4.1 Invalid Encoding . . . . . . . . . . . . . . 8
5.6.4.2 Protocol-version, Presentation-requirements . 8
5.6.4.3 Presentation-selector . . . . . . . . . . . . 8
5.7 SESSION . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.7.1 Introduction . . . . . . . . . . . . . . . . . . . 8
5.7.2 Services . . . . . . . . . . . . . . . . . . . . . 9
5.7.2.1 Session Services . . . . . . . . . . . . . . 9
5.7.2.2 Use of Transport Services . . . . . . . . . . 9
5.7.3 Protocol Agreements . . . . . . . . . . . . . . . 9
5.7.3.1 Concatenation . . . . . . . . . . . . . . . . 9
5.7.3.2 Segmenting . . . . . . . . . . . . . . . . . 10
5.7.3.3 Reuse of Transport Connection . . . . . . . . 10
5.7.3.4 Use of Transport Expedited Data . . . . . . . 10
5.7.3.5 Use of Session Version Number . . . . . . . . 10
5.7.3.6 Receipt of Invalid SPDUs . . . . . . . . . . 11
5.7.3.7 Invalid SPM Intersections . . . . . . . . . . 11
5.7.3.8 S-Selectors . . . . . . . . . . . . . . . . . 11
5.8 UNIVERSAL ASN.1 ENCODING RULES . . . . . . . . . . . . . . . 11
5.8.1 Tags . . . . . . . . . . . . . . . . . . . . . . . 12
5.8.2 Definite length . . . . . . . . . . . . . . . . . 12
5.8.3 EXTERNAL Type . . . . . . . . . . . . . . . . . . 12
5.9 CONFORMANCE . . . . . . . . . . . . . . . . . . . . . . . . 12
5.9.1 Specific ASE Requirements for ACSE Presentation and
Session . . . . . . . . . . . . . . . . . . . . . 12
5.9.1.1 FTAM . . . . . . . . . . . . . . . . . . . . 13
5.9.1.1.1 Phase 2 . . . . . . . . . . . . . . . . 13
5.9.1.2 MHS . . . . . . . . . . . . . . . . . . . . . 15
5.9.1.2.1 Phase 1 . . . . . . . . . . . . . . . . 15
5.9.1.3 DS . . . . . . . . . . . . . . . . . . . . . 16
5.9.1.3.1 Phase 1 . . . . . . . . . . . . . . . . 16
5.10 APPENDIX A: RECOMMENDED PRACTICES . . . . . . . . . . . . . 17
6. ISO FILE TRANSFER, ACCESS AND MANAGEMENT PHASE 2 . . . . . . . . 1
6.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . 1
6.2 SCOPE AND FIELD OF APPLICATION . . . . . . . . . . . . . . . 1
6.3 STATUS . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
6.4 ERRATA . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
6.5 ASSUMPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 4
6.6 PRESENTATION AGREEMENTS . . . . . . . . . . . . . . . . . . 5
6.7 SERVICE CLASS AGREEMENTS . . . . . . . . . . . . . . . . . . 6
6.8 FUNCTIONAL UNIT AGREEMENTS . . . . . . . . . . . . . . . . . 6
6.9 FILE ATTRIBUTE AGREEMENTS . . . . . . . . . . . . . . . . . 6
6.9.1 Mandatory Group . . . . . . . . . . . . . . . . . 7
6.9.2 Optional Groups . . . . . . . . . . . . . . . . . 7
6.10 DOCUMENT TYPE AGREEMENTS . . . . . . . . . . . . . . . . . . 8
6.10.1 Character Sets . . . . . . . . . . . . . . . . . . 11
6.10.1.1 IA5 Character Set . . . . . . . . . . . . . . 12
6.10.1.2 8859-1 Character Set . . . . . . . . . . . . 14
6.10.2 Document Type Negotiation Rules . . . . . . . . . 14
6.10.2.1 Connection Establishment . . . . . . . . . . 14
6.10.2.2 File Creation . . . . . . . . . . . . . . . . 14
6.10.2.3 File Opening . . . . . . . . . . . . . . . . 14
6.10.3 Relationship Between DUs, DEs and Document Types . 15
6.11 F-CANCEL ACTION . . . . . . . . . . . . . . . . . . . . . . 16
6.12 IMPLEMENTATION INFORMATION AGREEMENTS . . . . . . . . . . . 16
6.13 DIAGNOSTIC AGREEMENTS . . . . . . . . . . . . . . . . . . . 16
6.14 CONCURRENCY . . . . . . . . . . . . . . . . . . . . . . . . 18
6.15 REQUESTED ACCESS . . . . . . . . . . . . . . . . . . . . . . 18
6.16 SECURITY . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.16.1 Initiator Identity and Filestore Password . . . 19
6.16.2 Access Passwords . . . . . . . . . . . . . . . . 19
6.16.3 Implementation Responsibilities . . . . . . . . . 19
6.17 REQUIREMENT FOR CONFORMANT IMPLEMENTATIONS . . . . . . . . . 19
6.17.1 Interoperable Configurations . . . . . . . . . . . 20
6.17.2 Relationship to ISO 8571--The FTAM Standard . . . 21
6.17.3 Requirements for Document Type Support . . . . . . 21
6.17.4 Initiators . . . . . . . . . . . . . . . . . . . . 22
6.17.5 Responders . . . . . . . . . . . . . . . . . . . . 23
6.17.6 Senders . . . . . . . . . . . . . . . . . . . . . 24
6.17.6.1 Initiator Senders . . . . . . . . . . . . . . 25
6.17.6.2 Responder Senders . . . . . . . . . . . . . . 25
6.17.7 Receivers . . . . . . . . . . . . . . . . . . . . 25
6.17.7.1 Initiator Receivers . . . . . . . . . . . . . 26
6.17.7.2 Responder Receivers . . . . . . . . . . . . . 26
6.17.8 Minimum Ranges . . . . . . . . . . . . . . . . . . 26
6.17.9 Use of Lower Layer Services . . . . . . . . . . . 29
6.18 IMPLEMENTATION PROFILES . . . . . . . . . . . . . . . . . . 29
6.18.1 General Requirements for the Defined Implementation
Profiles . . . . . . . . . . . . . . . . . . . . . 30
6.18.2 Intentionally Left Empty . . . . . . . . . . . . . 30
6.18.3 Document Type Requirements for the Defined
Implementation Profiles . . . . . . . . . . . . . 30
6.18.4 Parameters for the Defined Implementation Profiles 31
6.18.5 Parameter Ranges for the Defined Implementation
Profiles . . . . . . . . . . . . . . . . . . . . . 32
6.18.6 File Attribute Support for Implementations . . . . 32
6.19 PROVISION OF SPECIFIC FUNCTION . . . . . . . . . . . . . . . 35
6.19.1 Implementation Profile T1: Simple File Transfer . 35
6.19.2 Implementation Profile T2: Positional File Transfer 35
6.19.3 Implementation Profile T3: Full File Transfer . . 36
6.19.4 Implementation Profile A1: Simple File Access . . 37
6.19.5 Implementation Profile A2: Full File Access . . . 37
6.19.6 Implementation Profile M1: Management . . . . . . 38
6.20 HARMONIZATION . . . . . . . . . . . . . . . . . . . . . . . 38
6.21 APPENDIX A: FTAM DOCUMENT TYPES . . . . . . . . . . . . . 39
7. CCITT 1984 X.400 BASED MESSAGE HANDLING SYSTEM . . . . . . . . . 1
7.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . 1
7.2 SCOPE . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
7.3 STATUS . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
7.4 ERRATA . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
7.5 PRMD to PRMD . . . . . . . . . . . . . . . . . . . . . . . . 3
7.5.1 Introduction . . . . . . . . . . . . . . . . . . . 3
7.5.2 Service Elements and Optional User Facilities . . 4
7.5.2.1 Classification of Support for Services . . . 4
7.5.2.1.1 Support (S) . . . . . . . . . . . . . . 5
7.5.2.1.2 Non Support (N) . . . . . . . . . . . . 5
7.5.2.1.3 Not Used (N/U) . . . . . . . . . . . . . 6
7.5.2.1.4 Not Applicable (N/A) . . . . . . . . . . 6
7.5.2.2 Summary of Supported Services . . . . . . . . 6
7.5.2.3 MT Service Elements and Optional User
Facilities . . . . . . . . . . . . . . . . . . . . 6
7.5.2.4 IPM Service Elements and Optional User
Facilities . . . . . . . . . . . . . . . . . . . . 8
7.5.3 X.400 Protocol Definitions . . . . . . . . . . . . 9
7.5.3.1 Protocol Classification . . . . . . . . . . . 10
7.5.3.2 General Statements on Pragmatic Constraints . 10
7.5.3.3 MPDU Size . . . . . . . . . . . . . . . . . . 11
7.5.3.4 P1 Protocol Elements . . . . . . . . . . . . 11
7.5.3.4.1 P1 Envelope Protocol Elements . . . . . 11
7.5.3.5 ORName Protocol Elements . . . . . . . . . . 16
7.5.3.6 P2 Protocol Profile (Based on [X.420]) . . . 18
7.5.3.6.1 P2 Protocol - Heading . . . . . . . . . 19
7.5.3.6.2 P2 Protocol - BodyParts . . . . . . . . 21
7.5.3.6.3 P2 BodyPart Protocol Elements . . . . . 23
7.5.4 Reliable Transfer Server (RTS) . . . . . . . . . . 25
7.5.4.1 Implementation Strategy . . . . . . . . . . . 25
7.5.4.2 RTS option selection . . . . . . . . . . . . 25
7.5.4.3 RTS Protocol Options and Clarifications . . . 26
7.5.4.4 RTS Protocol Limitations . . . . . . . . . . 29
7.5.5 Use of Session Services . . . . . . . . . . . . . 31
7.5.6 Data Transfer Syntax . . . . . . . . . . . . . . . 31
7.6 PRMD to ADMD and ADMD to ADMD . . . . . . . . . . . . . . . 31
7.6.1 Introduction . . . . . . . . . . . . . . . . . . . 31
7.6.2 Additional ADMD Functionality . . . . . . . . . . 33
7.6.2.1 Relay Responsibilities of an ADMD . . . . . . 33
7.6.2.2 P1 Protocol Classification Changes . . . . . 34
7.6.2.3 O/R Names . . . . . . . . . . . . . . . . . . 34
7.6.2.4 P1 ADMD Name . . . . . . . . . . . . . . . . 35
7.6.3 Interworking with Integrated UAs . . . . . . . . . 35
7.6.4 Differences with Other Profiles . . . . . . . . . 35
7.6.4.1 TTC Profile . . . . . . . . . . . . . . . . . 35
7.6.4.2 CEPT Profile . . . . . . . . . . . . . . . . 36
7.6.5 Connection of PRMDs to Multiple ADMDs . . . . . . 36
7.6.6 Connection of an ADMD to a Routing PRMD . . . . . 36
7.6.7 Management Domain Names . . . . . . . . . . . . . 37
7.6.8 Envelope Validation Errors . . . . . . . . . . . . 37
7.6.9 Quality of Service . . . . . . . . . . . . . . . . 38
7.6.9.1 Domain Availability . . . . . . . . . . . . . 38
7.6.9.1.1 ADMD Availability . . . . . . . . . . . 38
7.6.9.1.2 PRMD Availability . . . . . . . . . . . 38
7.6.9.2 Delivery Times . . . . . . . . . . . . . . . 38
7.6.10 Billing Information . . . . . . . . . . . . . . . 39
7.6.11 Transparency . . . . . . . . . . . . . . . . . . . 39
7.6.12 RTS Password Management . . . . . . . . . . . . . 40
7.6.13 For Further Study . . . . . . . . . . . . . . . . 40
7.7 INTER and INTRA PRMD CONNECTIONS . . . . . . . . . . . . . . 40
7.7.1 Introduction . . . . . . . . . . . . . . . . . . . 40
7.7.2 The Relaying PRMD . . . . . . . . . . . . . . . . 41
7.7.2.1 Relay Responsibilities of a PRMD . . . . . . 41
7.7.2.2 Interaction with an ADMD . . . . . . . . . . 41
7.7.3 Intra PRMD Connections . . . . . . . . . . . . . . 42
7.7.3.1 Relay Responsibilities of an MTA . . . . . . 42
7.7.3.2 Loop Suppression within a PRMD . . . . . . . 43
7.7.3.3 Routing Within a PRMD . . . . . . . . . . . . 44
7.7.3.3.1 Class Designations . . . . . . . . . . . 44
7.7.3.3.2 Specification of MTA Classes . . . . . . 46
7.7.3.3.3 Consequences of Using Certain Classes of
MTAs . . . . . . . . . . . . . . . . . . . . 46
7.7.3.4 Uniqueness of MPDUidentifiers Within a PRMD . 47
7.7.4 Service Elements and Optional User Facilities . . 47
7.7.5 X.400 Protocol Definitions . . . . . . . . . . . . 48
7.7.5.1 Protocol Classification . . . . . . . . . . . 48
7.7.5.2 P1 Protocol Elements . . . . . . . . . . . . 48
7.7.5.3 Reliable Transfer Server (RTS) . . . . . . . 51
7.8 ERROR HANDLING . . . . . . . . . . . . . . . . . . . . . . . 51
7.8.1 MPDU Encoding . . . . . . . . . . . . . . . . . . 52
7.8.2 Contents . . . . . . . . . . . . . . . . . . . . . 52
7.8.3 Envelope . . . . . . . . . . . . . . . . . . . . . 52
7.8.3.1 Pragmatic Constraint Violations . . . . . . . 52
7.8.3.2 Protocol Violations . . . . . . . . . . . . . 52
7.8.3.3 O/R Names . . . . . . . . . . . . . . . . . . 52
7.8.3.4 TraceInformation . . . . . . . . . . . . . . 53
7.8.3.5 InternalTraceInfo . . . . . . . . . . . . . . 54
7.8.3.6 Unsupported X.400 Protocol Elements . . . . . 54
7.8.3.6.1 deferredDelivery . . . . . . . . . . . . 54
7.8.3.6.2 PerDomainBilateralInfo . . . . . . . . . 55
7.8.3.6.3 ExplicitConversion . . . . . . . . . . . 55
7.8.3.6.4 alternateRecipientAllowed . . . . . . . 55
7.8.3.6.5 contentReturnRequest . . . . . . . . . . 55
7.8.3.7 Unexpected Values for INTEGER Protocol Elements 55
7.8.3.7.1 Priority . . . . . . . . . . . . . . . . 55
7.8.3.7.2 ExplicitConversion . . . . . . . . . . . 56
7.8.3.7.3 ContentType . . . . . . . . . . . . . . 56
7.8.3.8 Additional Elements . . . . . . . . . . . . . 56
7.8.4 Reports . . . . . . . . . . . . . . . . . . . . . 56
7.9 MHS USE OF DIRECTORY SERVICES . . . . . . . . . . . . . . . 56
7.9.1 Directory Service Elements . . . . . . . . . . . . 56
7.9.2 Use of Names and Addresses . . . . . . . . . . . . 57
7.10 CONFORMANCE . . . . . . . . . . . . . . . . . . . . . . . . 58
7.10.1 Introduction . . . . . . . . . . . . . . . . . . . 58
7.10.2 Definition of Conformance . . . . . . . . . . . . 58
7.10.3 Conformance Requirements . . . . . . . . . . . . . 60
7.10.3.1 Introduction . . . . . . . . . . . . . . . . 60
7.10.3.2 Initial Conformance . . . . . . . . . . . . . 60
7.10.3.2.1 Interworking . . . . . . . . . . . 61
7.10.3.2.2 Service . . . . . . . . . . . . . . 61
7.11 APPENDIX A: INTERPRETATION OF X.400 SERVICE ELEMENTS . . 62
7.12 APPENDIX B: RECOMMENDED X.400 PRACTICES . . . . . . . . . 66
7.12.1 RECOMMENDED PRACTICES IN P2 . . . . . . . . . . . 66
7.12.2 RECOMMENDED PRACTICES IN RTS . . . . . . . . . . . 66
7.12.3 RECOMMENDED PRACTICES FOR ORName . . . . . . . . . 67
7.12.4 POSTAL ADDRESSING . . . . . . . . . . . . . . . . 70
7.12.5 EDI use of X.400 . . . . . . . . . . . . . . . . . 71
7.12.5.1 Introduction and Scope . . . . . . . . . . . 71
7.12.5.2 Model . . . . . . . . . . . . . . . . . . . . 71
7.12.5.3 Protocol Elements Supported for EDI . . . . . 73
7.12.5.4 Addressing and Routing . . . . . . . . . . . 73
7.12.6 USA Body Parts . . . . . . . . . . . . . . . . . . 74
7.13 APPENDIX C: RENDITION OF IA5Text AND T61String CHARACTERS 75
7.13.1 GENERATING AND IMAGING IA5Text . . . . . . . . . . 75
7.13.2 GENERATING AND IMAGING T61String . . . . . . . . . 75
7.14 APPENDIX D: DIFFERENCES IN INTERPRETATION DISCOVERED
THROUGH TESTING OF THE MHS FOR THE CeBit 87
DEMONSTRATION . . . . . . . . . . . . . . . . 76
7.14.1 ENCODING OF RTS USER DATA . . . . . . . . . . . . 76
7.14.2 EXTRA SESSION FUNCTIONAL UNITS . . . . . . . . . . 76
7.14.3 MIXED CASE IN THE MTA NAME . . . . . . . . . . . . 77
7.14.4 X.410 ACTIVITY IDENTIFIER . . . . . . . . . . . . 77
7.14.5 ENCODING OF PER RECIPIENT FLAG AND PER MESSAGE FLAG 77
7.14.6 ENCODING OF EMPTY BITSTRINGS . . . . . . . . . . . 78
7.14.7 ADDITIONAL OCTETS FOR BITSTRINGS . . . . . . . . . 78
7.14.8 APPLICATION PROTOCOL IDENTIFIER . . . . . . . . . 78
7.14.9 INITIAL SERIAL NUMBER IN S-CONNECT . . . . . . . . 78
7.14.10 CONNECTION DATA ON RTS RECOVERY . . . . . . . . . 78
7.14.11 ACTIVITY RESUME . . . . . . . . . . . . . . . . . 78
7.14.12 OLD ACTIVITY IDENTIFIER . . . . . . . . . . . . . 79
7.14.13 NEGOTIATION DOWN TO TRANSPORT CLASS 0 . . . . . . 79
7.15 APPENDIX E: WORLDWIDE X.400 CONFORMANCE PROFILE MATRIX . 80
7.16 APPENDIX F: INTERWORKING WARNINGS . . . . . . . . . . . . 91
8. DIRECTORY SERVICES PROTOCOLS . . . . . . . . . . . . . . . . . . 1
8.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . 1
8.2 SCOPE AND FIELD OF APPLICATION . . . . . . . . . . . . . . . 2
8.3 STATUS . . . . . . . . . . . . . . . . . . . . . . . . . 3
8.4 USE OF DIRECTORIES . . . . . . . . . . . . . . . . . . . . . 3
8.5 DIRECTORY ASEs, APPLICATION CONTEXTS, AND PORTS . . . . . . 4
8.6 SCHEMAS . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.6.1 Maintenance of Structures and Naming Rules . . . . 5
8.6.2 Maintenance of object classes and subclasses . . . 6
8.6.3 Maintenance of Attribute Types . . . . . . . . . . 6
8.6.4 Maintenance of Attribute Syntaxes . . . . . . . . 6
8.7 CLASSIFICATION OF SUPPORT FOR ATTRIBUTE TYPES . . . . . . . 6
8.7.1 Mandatory Support . . . . . . . . . . . . . . . . 7
8.7.2 Optional Support . . . . . . . . . . . . . . . . . 7
8.8 INTORDUCTION TO PRAGMETIC CONSTRAINTS . . . . . . . . . . . 8
8.9 GENERAL CONSTRAINTS . . . . . . . . . . . . . . . . . . . . 8
8.9.1 Character Sets . . . . . . . . . . . . . . . . . . 8
8.9.2 APDU Size Considerations . . . . . . . . . . . . . 8
8.9.3 Service Control (SC) Considerations . . . . . . . 9
8.9.4 Priority Service Control . . . . . . . . . . . . . 9
8.10 CONSTRAINTS ON OPERATIONS . . . . . . . . . . . . . . . . . 10
8.10.1 Filters . . . . . . . . . . . . . . . . . . . . . 10
8.10.2 Errors . . . . . . . . . . . . . . . . . . . . . . 10
8.11 CONSTRAINTS ON ATTRIBUTE TYPES . . . . . . . . . . . . . . . 10
8.11.1 Attribute Values . . . . . . . . . . . . . . . . . 10
8.12 CONFORMANCE . . . . . . . . . . . . . . . . . . . . . . . . 15
8.12.1 DUA Conformance . . . . . . . . . . . . . . . . . 15
8.12.2 DSA Conformance . . . . . . . . . . . . . . . . . 16
8.12.3 Directory Systems Conformance Classes . . . . . . 17
8.12.4 Authentication Conformance . . . . . . . . . . . . 17
8.12.5 Authentication Conformance Classes . . . . . . . . 18
8.13 DISTRIBUTED OPERATIONS . . . . . . . . . . . . . . . . . . . 18
8.13.1 Referrals and Chaining . . . . . . . . . . . . . . 19
8.14 UNDERLYING SERVICES . . . . . . . . . . . . . . . . . . . . 19
8.14.1 ROSE . . . . . . . . . . . . . . . . . . . . . . . 19
8.14.2 Session . . . . . . . . . . . . . . . . . . . . . 19
8.15 ACCESS CONTROL . . . . . . . . . . . . . . . . . . . . . . . 19
8.16 AUTHENTICATION . . . . . . . . . . . . . . . . . . . . . . . 19
8.17 TEST CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . 20
8.17.1 Major elements of Architecture . . . . . . . . . . 20
8.17.2 Search Operation . . . . . . . . . . . . . . . . . 21
8.18 ERRORS . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.18.1 Permanent vs. Temporary Service Errors . . . . . . 21
8.19 APPENDIX A Definitions . . . . . . . . . . . . . . . . . 22
8.20 APPENDIX B Attributes and Object Classes . . . . . . . . 23
8.21 APPENDIX C The Use of ROSE . . . . . . . . . . . . . . . 28
8.22 APPENDIX D Guidelines . . . . . . . . . . . . . . . . . 29
8.23 APPENDIX E Glossary . . . . . . . . . . . . . . . . . . 30
9. SECURITY . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
9.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . 1
9.2 Matrix of Security Services and OSI Layers . . . . . . . . . 2
10. OBJECT IDENTIFIER: STRUCTURE AND ALLOCATION . . . . . . . . 1
10.1 Specific ASE Requirements for ACSE Presentation and Session 5
10.1.1 FTAM . . . . . . . . . . . . . . . . . . . . . . . 5
10.1.1.1 Phase 2 . . . . . . . . . . . . . . . . . . . 5
10.1.2 MHS . . . . . . . . . . . . . . . . . . . . . . . 8
10.1.2.1 Phase 1 . . . . . . . . . . . . . . . . . . . 8
10.1.3 DS . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1.3.1 Phase 1 . . . . . . . . . . . . . . . . . . . 9
11. REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . 1
11.1 CCITT . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
11.2 ISO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
11.3 IEEE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
11.4 NBS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.5 MAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.6 TOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.7 CEN/CENELEC . . . . . . . . . . . . . . . . . . . . . . . . 10
11.8 SPAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
List of Figures
Figure 2.1 LSAP bit pattern . . . . . . . . . . . . . . . . . . . 1
Figure 2.2 I-Field Format . . . . . . . . . . . . . . . . . . . . . 4
Figure 4.1 AK exchange on idleconnection . . . . . . . . . . . . . 6
Figure 6.1 Model of file transfer/access . . . . . . . . . . . . . 2
Figure 7.1 The layered structure of this implementation agreement . 1
Figure 7.2 This agreement applies to the interface between: (A) PRMD
and PRMD; (B) PRMD and ADMD; (C) ADMD and ADMD; and (D)
MTA and MTA . . . . . . . . . . . . . . . . . . . . . . . 3
Figure 7.3 Interconnection of private domains . . . . . . . . . . . 4
Figure 7.4 X.409 Definition of Privately Defined BodyParts . . . . 22
Figure 7.5 An ADMD may (b) or may not (a) serve as a relay . . . . 33
Figure 7.6 Relaying PRMD . . . . . . . . . . . . . . . . . . . . . 41
Figure 7.7 Intra PRMD connections . . . . . . . . . . . . . . . . . 42
Figure 7.8 MD C must know of A to route the message . . . . . . . . 42
Figure 7.9 Definition of InternalTraceInfo . . . . . . . . . . . . 43
Figure 7.10 Defined Actions in MTASuppliedInfo . . . . . . . . . . . 44
Figure 7.11 Example of a confirguration to be avoided . . . . . . . 47
Figure 8.1 Structure of this Implementation Agreement . . . . . . . 1
Figure 8.2 Centralized Directory Model . . . . . . . . . . . . . . 2
Figure 8.3 Distributed Directory Model . . . . . . . . . . . . . . 3
Figure 8.4 Access to the Directory . . . . . . . . . . . . . . . . 5
Figure 8.5 APDU Exchange . . . . . . . . . . . . . . . . . . . . . 8
Figure 8.6 Logical DSA Application Environment . . . . . . . . . . 9
List of Tables
Table 5.1 Session States . . . . . . . . . . . . . . . . . . . . . 18
Table 5.2 Incoming Events . . . . . . . . . . . . . . . . . . . . . 19
Table 6.1 Parameters for FTAM-1, -2, -3 . . . . . . . . . . . . . . 8
Table 6.2 Parameters for NBS-6, NBS-7, NBS-8 . . . . . . . . . . . 10
Table 6.3 FTAM primitive data types . . . . . . . . . . . . . . . . 11
Table 6.4 IRV Graphic Character Allocations . . . . . . . . . . . . 13
Table 6.5 Interoperable configurations . . . . . . . . . . . . . . 21
Table 6.6 Required minimal parameter support . . . . . . . . . . . 27
Table 6.7 Implementation profile support requirements . . . . . . . 34
Table 6.8 Implementation Profiles (NBS) and Profiles (SPAG/CEN-CLC) 38
Table 6.9 Information objects in NBS-6 . . . . . . . . . . . . . . 41
Table 6.10 Information objects in NBS-7 . . . . . . . . . . . . . . 46
Table 6.11 Information objects in NBS-8 . . . . . . . . . . . . . . 50
Table 6.12 Datatypes for keys . . . . . . . . . . . . . . . . . . . 52
Table 6.12 Information objects in NBS-9 . . . . . . . . . . . . . . 56
Table 6.14 Basic constraints for NBS Ordered flat . . . . . . . . . 60
Table 6.15 Identity constraints in NBS Ordered flat . . . . . . . . 61
Table 7.1 Basic MT service elements . . . . . . . . . . . . . . . 6
Table 7.2 MT optional user facilities provided to the UA-selectable on
a per-message basis . . . . . . . . . . . . . . . . . . . 7
Table 7.3 MT optional user facilities provided to the UA agreed for
any contractual period of time . . . . . . . . . . . . . . 7
Table 7.4 Basic IPM service elements . . . . . . . . . . . . . . . 8
Table 7.5 IPM optional facilities agreed for a contractual period of
time . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Table 7.6 IPM optional user facilities selectable on a per-message
basis . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Table 7.7 Protocol Classifications . . . . . . . . . . . . . . . . 10
Table 7.8 P1 protocol elements . . . . . . . . . . . . . . . . . . 12
Table 7.9 ORName protocol elements . . . . . . . . . . . . . . . . 17
Table 7.10 P2 heading protocol elements . . . . . . . . . . . . . . 19
Table 7.11 P2 BodyParts . . . . . . . . . . . . . . . . . . . . . . 23
Table 7.12 Checkpoint window size of IP . . . . . . . . . . . . . . 29
Table 7.13 RTS protocol elements . . . . . . . . . . . . . . . . . 30
Table 7.14 P1 Protocol Classification Changes for a Delivering ADMD 34
Table 7.15 Delivery Time Targets . . . . . . . . . . . . . . . . . 38
Table 7.16 Forced Nondelivery Times . . . . . . . . . . . . . . . . 39
Table 7.17 Conformant MTA Classifications . . . . . . . . . . . . . 45
Table 7.18 P1 Protocol Elements . . . . . . . . . . . . . . . . . . 49
Table 7B.1 Printable string to ASCII mapping . . . . . . . . . . . 69
Table 7E.1 Protocol element comparison of RTS . . . . . . . . . . . 81
Table 7E.2 Protocol element comparison of P1 . . . . . . . . . . . 83
Table 7E.3 Protocol element comparison of P2 . . . . . . . . . . . 88
Table 8.1 Pragmatic Constraints for Selected Attributes. . . . . . 12
Table 9.1 OSI Layers Desirable for Placing Security . . . . . . . . 3
1. GENERAL INFORMATION
1.1 PURPOSE OF THIS DOCUMENT
This document records stable implementation agreements of OSI
protocols among the organizations participating in the NBS Workshop
for Implementors of OSI. Stable in the context of this document
means that:
1) The agreements are based on final standards
(e.g., ISO-IS or CCITT Recommendations) or
nearly final (e.g., ISO-DIS) with no
significant changes expected, and,
2) The agreements have been approved by the NBS
Workshop Plenary for progression from the "On-
Going" agreements document to the draft stable
agreements document and after a period of
review have been passed to these final stable
agreements. The only changes allowed will be
clarifications, errata and the correction of
omissions discovered in their implementation.
For these reasons, the agreements are considered advanced enough for
use in product and test suite development, as well as for procurement
references.
Future releases of these Stable Agreements will add and/or extend
functionality offered by this version. When required, new versions
will be introduced on a yearly basis. It is the NBS Workshop intent
that new versions of this Stable Agreements document will be
compatible with the present version. If this proves impractical, the
agreements will attempt to provide mechanisms and guidelines which
maximize interoperability.
1.2 PURPOSE OF THE WORKSHOP
In February, 1983, at the request of industry, NBS organized the NBS
Workshop for Implementors of OSI to bring together future users and
potential suppliers of OSI protocols. The workshop accepts as input
the specifications of emerging standards for protocols and produces as
output agreements on the implementation and testing particulars of
these protocols. This process is expected to expedite the development
of OSI protocols and promote interoperability of independently
manufactured data communications equipment.
1.3 WORKSHOP ORGANIZATION
The Workshop organizes its work through Special Interest Groups
(SIGs) that prepare technical documentation. An executive committee
of SIG chairpersons led by the overall Workshop chairperson
administers the workshop. NBS invites highly qualified technical
leaders from participating organizations to assume leadership roles in
the SIGs. The SIGs are encouraged to coordinate with standards
organizations and user groups, and to seek widespread technical
consensus on implementation agreements through international
discussions and liaison activities.
The Workshop meets four times a year at the National Bureau of
Standards in Gaithersburg, Maryland where each SIG is required to
convene its meeting. In addition, a plenary assembly of all workshop
delegates is convened for consideration of SIG motions and other
workshop business. SIGs are also encouraged to hold interim meetings
at varied locations around the world.
The Workshop is an open public forum. Registration materials,
documents, and workshop schedules are available from:
National Bureau of Standards
NBS Workshop for Implementors of OSI
Building 225, Room B-217
Gaithersburg, Maryland 20899
2. SUB NETWORKS
2.1 INTRODUCTION
This chapter provides agreements about subnetwork services used in
providing the OSI Network Layer.
2.2 SCOPE AND FIELD OF APPLICATION
These agreements cover subnetwork types including local area networks,
packet switched networks, circuit switched networks, ISDN, and others.
2.3 STATUS
This version was completed on December 18, 1987.
Ongoing work for other agreements and for future versions of these
agreements is contained in the "On-Going" agreements document,
including provisions for ISDN.
2.4 ERRATA
2.5 LOCAL AREA NETWORKS
2.5.1 IEEE 802.2 LOGICAL LINK CONTROL
The following decisions have been reached with respect to this
protocol.
l. Link Service Access Point (LSAP)
The IEEE 802 committee has assigned the code below to
address systems using any ISO network layer protocol. Note
that bit zero is transmitted first.
The most significant bit is bit 7, thus this bit pattern
represents hexadecimal FE.
0 l 2 3 4 5 6 7
ZDDDBDDDBDDDBDDDBDDDBDDDBDDDBDDD?
3 0 3 l 3 l 3 l 3 l 3 l 3 l 3 1 3
@DDDADDDADDDADDDADDDADDDADDDADDDY
Figure 2.1 LSAP bit pattern
2. Type and Class
Only the connectionless type l, class l IEEE 802 link
service will be used.
2.5.2 IEEE 802.3 CSMA/CD ACCESS METHOD
The following implementation agreements have been reached with
respect to the IEEE 802.3 CSMA/CD Access Method and Physical
Layer Specifications: for 10 BASE 5:
o The address length shall be 48 bits
The following implementation agreements have been reached with
respect to 10 BROAD 36 Networks:
1. Single Cable Networks
- The translator frequency shall be 192.25 Mhz
- The channel allocations are
Reverse Channels Forward Channels
T12, T13, T14 L, M, N
T13, T14, 2' M, N, O
T14, 2', 3' N, O, P
2', 3', 4' O, P, Q
3', 4', 4A' P, Q, R
4', 4A', 5' Q, R, S
2. Dual Cable Networks
For nontranslated dual cable networks forward and
reverse frequencies are the same. Permissible
channel allocations are:
T12, T13, T14
T13, T14, 2'
T14, 2', 3'
2', 3', 4'
3', 4', 4A'
4', 4A', 5'
L, M, N
M, N, O
N, O, P
O, P, Q
Q, R, S
3. When both IEEE 802.4 and IEEE 802.3 10 BROAD 36
networks coexist on the broadband cable system the
preferred channel allocations are:
Reverse Forward
IEEE 802.3 T12, T13, T14 L, M, N
IEEE 802.4 6', FM1' T, U
channels 3', 4' P, Q
reserved for 4A', 5' R, S
future use
2.5.3 IEEE 802.4 TOKEN BUS ACCESS METHOD
The following options are agreed to with respect to Draft J of
token bus:
o Data Rate:
- 10 Mb (Broadband)
- 5 Mb (carrierband)
o Addressing: 48 bit
o The lmeOption, Priority Mechanism, shall be implemented
o Broadband Channel Assignments
Forward Reverse
P 3'
Q 4'
R 4A'
S 5'
T 6'
U FM1'
2.5.4 IEEE 802.5 TOKEN RING ACCESS METHOD
The following implementation agreements have been reached with
respect to the IEEE Standard 802.5, Token Passing Ring Access
Method and Physical Layer specification.
o The data signalling rate shall be 4 Mbit/s
o The address length shall be 48 bits
o The message priority (PM) of the AMP data unit shall be
7
o The ALL_STATIONS_THIS_RING_ADDRESS shall be
X'COOOFFFFFFFF'
o The TRR value shall be 4 milliseconds
o The THT value shall be 8.9 milliseconds
o The TQP value shall be 20 milliseconds
o The TVX value shall be 10 milliseconds
o The TNT value shall be 2.6 milliseconds
o The TAM value shall be 7 seconds
o The TSM value shall be 15 seconds
o The MAC Information field (I-field) shall be defined as
follows:
ZDDDDDDDDDDDDDDDDDDDBDDDDDDDDDDDDDDDDDDBDDDDDDDDDDDDDDDD?
3 Starting Sequence 3 I-Field 3 End Sequence 3
@DDDDDDDDDDDDDDDDDDDADDDDDDDDDDDDDDDDDDADDDDDDDDDDDDDDDDY
and the:
1) Starting Sequence includes: SD, AC, FC, DA, SA
2) Ending Sequence includes: FCS, ED, FS
Figure 2.2 I-Field Format
o With the above timer and MAC I-field definitions, the
following limits are defined:
- Protocol limits the I-field to a maximum of 4425
bytes.
- All stations shall support I-fields that have a
minimum of one byte and a maximum of at least 2000
bytes.
2.6 WIDE AREA NETWORKS
2.6.1 CCITT RECOMMENDATION X.25
The procedures required to describe the DTE/DTE interface and the
DTE side of the DTE/DCE interface, for systems attached to
subnetworks providing an X.25 interface shall be as defined in
ISO 7776 and ISO 8208.
3. NETWORK LAYER
3.1 INTRODUCTION
This chapter presents agreements for providing the OSI network
service. Also contained here are agreements on network layer
addressing and routing.
3.2 SCOPE AND FIELD OF APPLICATION
These agreements cover both connectionless-mode and connection-mode
network services.
3.3 STATUS
This version of the agreements was completed on December 18, 1987.
Ongoing work for other agreements and for future versions of these
agreements is contained in the "On-Going" agreements document,
including provisions for ISDN, and including specific aspects of using
the X.25 PLP over LANs.
3.4 ERRATA
3.5 CONNECTIONLESS-MODE NETWORK SERVICE (CLNS)
3.5.1 Provision of CLNS over Local Area Networks (LANS)
When providing CLNS over a LAN subnetwork, the following shall
apply:
1. The definition of CLNS shall be as specified in ISO
8348/AD1.
2. The protocol used to provide CLNS shall be ISO 8473
with agreements as specified in 3.5.3.1.
3.5.2 Provision of CLNS over X.25 Subnetworks
When providing CLNS over X.25 subnetworks, the following shall
apply:
1. The definition of CLNS shall be as specified in ISO
8348/AD1.
2. The protocol used to provide CLNS shall be ISO 8473
with agreements as specified in 3.5.3.1.
3. The necessary subnetwork dependant convergence function
shall be as defined in ISO 8473 for operation over X.25
subnetworks, with agreements as specified in 3.5.3.2.
4. The X.25 PLP shall be as defined in ISO 8208.
3.5.3 Agreements on Protocols
3.5.3.1 ISO 8473
1. Subsets of the protocol:
o Implementations will not transmit PDUs encoded
using the inactive subset. Received PDUs encoded
using the inactive subset will be discarded.
o The non-segmenting subset will not be used.
Implementations will not generate data PDUs
without a segmentation part. However,
implementations will receive and correctly process
PDUs which do not contain the segmentation part.
2. Mandatory Functions:
o The lifetime parameter shall be used as specified
in section 6.4 of ISO 8473. The parameter shall
have an initial value of at least three times the
network span or three times the maximum transit
delay (in units of 500 milliseconds), whichever is
greater.
o The reassembly timer for an initial PDU at the
reassembly point shall be no greater than the
largest value of all lifetime parameters contained
in all derived PDUs.
3. Optional Functions:
o The Security parameter is not defined by these
Agreements. Implementations shall not transmit
the parameter except where defined by bilateral
agreements.
o Partial and complete source Routing will not be
supported.
o Partial record of Route will be supported by
Intermediate systems.
o ISO 8473 will be followed with respect to QOS.
3.5.3.2 Subnetwork Dependent Convergence Function
1. When 8473 SNDC functions are used over X.25
subnetworks, the default throughput class shall be used
if this facility is available.
3.6 CONNECTION-MODE NETWORK SERVICE (CONS)
The following agreements concern provision of the connection-mode
Network Service.
3.6.1 Mandatory Method of Providing CONS
When providing CONS using X.25 1984, the following shall apply:
o The definition of the CONS is as specified in ISO 8348,
Network Service Definition.
o The mapping of the elements of the CONS to the elements of
the X.25 Packet Level Protocol (PLP) is as specified in ISO
8878, Use of X.25 to Provide the Connection-mode Network
Service.
o The general procedures and formats of the X.25 PLP are as
specified in ISO 8208, X.25 Packet Level Protocol for Data
Terminal Equipment.
3.6.2 Additional Option: Provision of CONS over X.25 1980
Subnetworks
When providing CONS over an X.25 1980 subnetwork, the following
shall apply:
o The definition of the CONS is as specified in ISO 8348,
Network Service Definition.
o The subnetwork dependant convergence protocol required
to provide CONS shall be as specified in ISO 8878 Annex
A, and referred to as the Alternative Procedures for
Network Connection Establishment and Release, with
agreements as defined in 3.6.3.2.
3.6.3 Agreements on Protocols
3.6.3.1 ISO 8878
o The Receipt Confirmation service will not be provided,
so the corresponding protocol elements need not be
implemented.
o The Expedited Data service will not be provided, so the
corresponding protocol elements need not be
implemented.
o Where the ISO 8208 diagnostic codes are not provided,
all Cause/Diagnostic code combinations can be mapped
to the Originator/Reason code of "Undefined".
3.6.3.2 Subnetwork Dependent Convergence Protocol (ISO
8878/Annex A)
o The Receipt Confirmation service will not be provided,
so the corresponding protocol elements need not be
implemented.
o The Expedited Data service will not be provided, so the
corresponding protocol elements need not be
implemented.
3.7 ADDRESSING
Address formats supported will conform to ISO 8348 DAD2.
o NSAP address formats will have a hierarchical structure.
This will reduce the size of routing tables.
o If used in the Domain Specific Part (DSP), an NSAP selector
shall be the least significant component in the hierarchy.
The NSAP selector shall not be used to preform routing; it
is simply intended to identify the network service user at
the destination end system. For those implementations
using an NSAP selector, there shall be one and only one
selector for each NSAP within the end system. All NSAP
addresses identifying a given NSAP will use the same NSAP
selector value.
3.8 ROUTING
3.8.1 Static Routing
End systems and intermediate systems supporting static routing
will provide a local mechanism to update and, if necessary, to
create the local routing table. Updating and consistency
checking will be performed by human operators. The algorithms
and data structures used for static routing are not specified in
these agreements. Implementors are free to perform these
functions in the manner which is most appropriate to their system
environment.
3.8.2 End System to Intermediate System
Dynamic routing between end systems and intermediate systems is
performed using the protocol described in ISO 9542, End System to
Intermediate System Routing Exchange Protocol for use in
conjunction with ISO 8473. The following agreements apply to the
use of this protocol over LANs and point-to-point links.
1. Implementations must support any valid NSAP format. For
the purposes of the protocol, NSAP addresses are
treated simply as octet strings.
2. Implementations must support both Configuration
Information and Route Redirection Information. No
subsets are permitted.
3. All timer values must be settable using local system
management.
4. Use of checksums must be settable using local system
management. Under normal use, checksums will be
disabled.
5. The QOS, Security and Priority parameters should not be
used for routing. For conformance, Intermediate
systems must transmit these parameters in RD PDUs if
they are present in the data PDU which generated the
redirect. However, End systems must ignore them in
received RD PDUs.
6. Both ES and IS implementations must support the
'optimization' described in Clause A.3 of ISO 9542 for
system initialization. Its use must be selectable
using local system management.
7. This protocol employs the same LSAP as ISO 8473.
8. The encoding of the BSNPA address follows the syntax
rules for the data link being used. On a LAN, for
example, it is a 48-bit MAC address.
9. The multicast addresses corresponding to "All
Intermediate Systems on the network" (All_ISN) and "All
End Systems on the network" (All_ESN) shall default to
the following:
All_ISN = 0900 2B00 0004
All_ESN = 0900 2B00 0005
10. The ES-IS protocol should be primarily responsible for
updating the Network Layer Routing Information Base
(RIB). In addition, a management mechanism capable of
adding and deleting "static" entries into the RIB is
recommended. When using the management mechanism to
add an entry, there should be no holding timer, and the
entry should be write protected from alteration by the
ES-IS protocol.
Note: This function enables route table entries to be
made which are static in nature. The use of
static entries is not intended for normal
operations, but rather is provided for test and
debug as well as for interoperation with other OSI
implementations which do not support the ES-IS
protocol.
3.9 MIGRATION CONSIDERATIONS
This section considers problems arising from evolving OSI standards
and implementations based on earlier versions of OSI standards.
3.9.1 X.25-1980
Until there is widespread availability of 1984 X.25 service, it
will be necessary for X.400 systems to use those existing packet-
switched public data networks which offer only pre-1984 X.25
service. While 1980 X.25 does not provide the CONS as defined by
ISO 8348, there is no implication of non-conformance to these
Agreements resulting there from for systems using 1980 X.25 to
interchange data at the Network Layer, provided they conform in
all other respects.
This is an exception to the Agreements for providing the OSI
Network Service, granted temporarily for practical reasons. This
exception will be removed when it is deemed to be no longer
necessary, in the judgement of the Workshop. While this
provision is in effect, it provides an alternative method of
using 1980 X.25 to the provisions of 3.6.2
3.10 CONFORMANCE
4. TRANSPORT
4.1 INTRODUCTION
These agreements support the integration of LANs, packet networks, and
other WANs with the smallest possible set of mandatory protocol sets,
in accordance with the other agreements already reached. Nothing here
shall preclude vendors from implementing protocol suites in addition
to the ones described in this document.
4.2 SCOPE AND FIELD OF APPLICATION
Two connection-oriented transport classed have been identified for
implementation: classes 0 and 4. Transport class 4 is endorsed for
use over CLNS and CONS. Transport class 0 is endorsed for use over
CONS.
4.3 STATUS
Completed March 1987.
4.4 ERRATA
4.5 TRANSPORT CLASS 4
4.5.1 Transport Class 4 Overview
Transport class 4 is mandatory for communication between systems
using the OSI CLNS and may also be used for systems using the OSI
CONS (i.e., a private MHS, etc.).
4.5.2 Protocol Agreements
The full protocol will be available including expedited data and
negotiation at connection establishment. A disconnect request
shall be issued in response to a connect request when the maximum
number of transport connections is reached or exceeded.
4.5.2.1 Rules for Negotiation
o In general, the ISO rules for negotiation will be used,
specifics follow.
o All implementations will send the l6/3l window
size/sequence space in the CR TPDU. Implementations
must all provide the l6/3l ISO option. Implementations
must be able to accept the 4/7 in a CR TPDU.
o The ISO maximum TPDU size is negotiable between l28 and
8K octets, always negotiated downward. The ISO rules
are to be followed, allowing any valid size in the CR
TPDU. TPDU size negotiation is a local implementation
issue. Each vendor will decide how it is implemented
in their end system.
o The security parameter is optional and user defined in
the ISO specification. Implementations should not send
the security parameter in the CR TPDU; if received the
parameter should be ignored.
o The use of checksums shall be as specified in ISO 8073
section 6.5.4., i.e., checksum shall be used unless
both transports explicitly agree negotiate to its non-
use. Requesting its non-use is an implementation
choice. All implementations must be able to operate
with checksums.
o Use of acknowledgement time parameter is optional in
ISO 8073. If an implementation is operating any policy
which delays the transmission of AK TPDUs, the maximum
amount of time by which a single AK TPDU may be delayed
shall be indicated to the peer transport service
provider using the acknowledgement time parameter. The
value transmitted should be expressed in units of
milliseconds and rounded up to the nearest whole
millisecond.
o Throughput, priority, and transit delay are optional in
the ISO specification. Do not send in the CR TPDU;
ignore in the CC TPDU.
o User data in the CR TPDU and the CC TPDU are optional.
No implementation should send; all implementations must
be prepared to receive.
o An unknown parameter in any received CR TPDU shall be
ignored.
o Known parameters with invalid values in a CR TPDU shall
be handled as follows:
Parameter Action
TSAP id Send DR TPDU
TPDU size ignore parm, use default
Version ignore parm, usedefault
Protection (Security) implementation dependent
Checksum discard CR TPDU
Additional Options Protocol Error
Alternate Protocol Classes Protocol Error
Acknowledge Time ignore parm
Throughput ignore parm
Residual Error Rate ignore parm
Priority ignore parm
Transit Delay ignore parm
4.5.2.2 TRANSPORT CLASS 4 SERVICE ACCESS POINTS OR
SELECTORS
The TSAP selector field in the CR and CC TPDUs shall be
encoded as a variable length field and will be interpreted
as an octet string. The length of the string cannot exceed
32 octets.
4.5.2.3 Retransmission Timer
It is recommended that the value used for the retransmission
timer be based upon the round-trip delay experienced on a
transport connection. The implementation should maintain,
and continually update, an estimate of the round-trip delay
for the TC. From this estimate, a value for the
retransmission timer is calculated each time it is started.
An example technique for maintaining the estimate and
calculating the retransmission timer is described below.
The value of the retransmission timer may be calculated
according to the following formula:
tT1 <DDD kE + AR
In this formula, E is the current estimate of the round-trip
delay on the transport connection, AR is the value of the
acknowledgement time parameter received from the remote
transport service provider during connection establishment,
and k is some locally administered factor.
A value for k should be chosen to keep the retransmission
timer sufficiently small such that lost TPDUs will be
detected quickly, but not so small that false alarms are
generated causing unnecessary retransmission.
The value of E may be calculated using an exponentially
weighted average based upon regular sampling of the interval
between transmitting a TPDU and receiving the corresponding
acknowledgement. Samples are taken by recording the time of
day when a TPDU requiring acknowledgement is transmitted and
calculating the difference between this and the time of day
when the corresponding acknowledgement is received. New
samples are incorporated with the existing average according
to the following formula.
E <DDD E + (1 - `)(S - E)
In this formula, S is the new sample and ` is a parameter
which can be set to some value between 0 and 1. The value
chosen for ` determines the relative weighting placed upon
the current estimate and the new sample. A large value of `
weights the old estimate more heavily causing it to respond
only slowly to variations in the round-trip delay.
A small value weights the new sample more heavily causing a
quick response to variations. (Note that setting ` to 1 will
effectively disable the algorithm and result in a constant
value for E, being that of the initial seed.)
If ` is set to 1-2-n for some value of n, the update can be
reduced to a subtract and shift as shown below.
E <DDD E + 2-n (S - E)
When sampling, if an AK TPDU is received which acknowledges
multiple DT TPDUs, only a single sample should be taken
being the round-trip delay experienced by the most recently
transmitted DT TPDU. This attempts to minimize in the
sample any delay caused by the remote transport service
provider withholding AK TPDUs.
4.5.2.4 Keep-Alive Function
The Class 4 protocol detects a failed transport connection
by use of an 'inactivity timer'. This timer is reset each
time a TPDU is received on a connection. If the timer ever
expires, the connection is terminated.
The Class 4 protocol maintains an idle connection by
periodically transmitting an AK TPDU upon expiration of the
'window timer'. Thus, in a simple implementation, the
interval of one transport entity's window timer must be less
than that of its peer's inactivity timer, and vice versa.
The following agreements permit communicating transport
entities to maintain an idle connection without shared
information about timer values.
o In accordance with ISO 8073, clause 12.2.3.9.a,
all implementations must respond to the receipt
of a duplicate AK TPDU not containing FCC by
transmitting an AK TPDU containing the 'flow
control confirmation' parameter.
o Implementations must always transmit duplicate AK
TPDUs without FCC on expiration of the local
window timer (see ISO 8073, clause 12.2.3.8.1).
Receipt of this TPDU by the remote transport
entity will cause it to respond with an AK TPDU
containing the 'flow control confirmation'
parameter. When this is received by the local
transport entity, it will reset its inactivity
timer. See figure 4.1.
o It is a local matter for an implementation to set
the intervals of its timers to appropriate
relative values. Specifically:
o The window timer must be greater than the
round-trip delay. See section 4.1.4.
o The inactivity timer must be greater than two
times the window timer; and should normally be an
even greater multiple if the transport connection
is to be resilient to the loss of an AK TPDU.
A duplicate AK TPDU (See Figure 4.1) is one which contains
the same values for YR-TU-NR, credit, and subsequence number
as the previous AK TPDU transmitted. A duplicate AK TPDU
does not acknowledge any new data, nor does it change the
credit window.
I W
3 3 3 3
3 3 3 3
3 DDDDEDDDD 3 duplicate 3
3 expire 3 3 AK 3
3 3 3 3
DDDDEDDDD 3 3 AK + FCC 3
reset 3 3 3 3
3 3 3 3
3 3 3 3
3 DDDDEDDDD 3 duplicate 3
3 expire 3 3 AK 3
3 3 3 3
3 3 3 3
DDDDEDDDD 3 3 AK + FCC 3
reset 3 3 3 3
3 3 3 3
3 3 3 3
3 DDDDEDDDD 3 3
3 expire 3 3 3
3 3 3 3
3 3 3 3
Figure 4.1 AK exchange on idleconnection
4.6 TRANSPORT CLASS 0
4.6.1 Transport Class 0 Overview
Transport class 0 over X.25 is mandatory (see X.400) for use in
communicating with public MHS systems operating in accordance
with the CCITT X.400 series recommendations. The purpose of the
agreements concerning transport class 0 is to allow connection to
these public services. Transport class 0 over X.25 can also be
used in communicating between PRMDs (this choice is prevalent
outside North America).
4.6.2 Protocol Agreements
Transport Class 0 agreements follow:
o The Error (ER) TPDU may be used at any time and upon
receipt requires that the recipient disconnect the
network connection, and by extension the transport
connection.
o The allowed values for the maximum TPDU size are as
specified in ISO 8073. They are: 128, 256, 512, 1024,
and 2048.
o The class 0 protocol does not support multiplexing. At
any instant, one transport corresponds to one network
connection.
o It is recommended that the optional timers TS1 and TS2,
if implemented, be settable by local system management.
Values in the order of minutes should be supported.
o An unlimited TSDU length must be supported.
4.6.2.1 TRANSPORT CLASS 0 SERVICE ACCESS POINTS
For communicating with public MHS systems, Section 5 of
X.410 specifies the use and format of TSAP identifiers.
4.6.3 Rules for Negotiation
The ISO rules for negotiations will be used.
5. UPPER LAYERS
5.1 INTRODUCTION
In this portion of the Implementors' Agreements, the NBS Upper Layers
SIG is primarily concerned with providing implementation agreements
for ACSE, and the Presentation and Session layers, so that systems
implemented according to these agreements can successfully
interoperate.
5.1.1 References
All documents referenced in the Upper Layers section of these
agreements can be found in the REFERENCES section of this NBS
Implementors' Agreements document.
5.2 SCOPE AND FIELD OF APPLICATION
This section does not detail particular conformance statements for
ACSE, Presentation, and Session, since what is to be implemented in
each case depends on which Application Service Elements (ASE's) and
which functional units within each ASE are used with an Application
Process. Each ASE's SIG must specify which functional units of each
layer it requires. However, the scope of each layer is based on the
total indicated requirements of all ASE's for which there is an active
NBS SIG. The implementation agreements are not specified beyond that
scope.
It is not the intent of this document to specify or reproduce
standards, but when a referenced standard is unclear or has known
defects, an attempt will be made to remedy the problem herein. Any
attempted clarification should be considered as a possible
interpretation; the ISO standard still takes precedence if there is
any conflict. The situation with respect to defects in a standard is
somewhat different; a reported defect may be technically resolved by
the appropriate international technical committee with likely approval
by the voting members pending for several months. Since relevant
defects can't be ignored in an implementation, this document will
recommend using defect resolutions which have the tentative approval
of the appropriate standards committees.
5.3 STATUS
This document is the first stable version of the NBS UL SIG.
5.4 ERRATA
5.4.1 ISO Defect Reports
This section lists the defect reports from ISO which are
currently recognized to be valid for the purposes of NBS
conformance.
5.4.2 Session Defects
These defects are listed for the benefit of X.400
implementations.
The following 8326 defect reports have been incorporated into
version 1 of Session:
004, 006, 007, 009, 011, 012, 013, 014, 015, 016, 017, 020.
The following 8327 defect reports have been incorporated into
version 1 of Session:
001, 003, 004, 005, 006, 007, 008, 009, 010, 012, 017, 018,
019, 026, 027, 030, 034, 035.
5.5 ASSOCIATION CONTROL SERVICE ELEMENT
5.5.1 Introduction
This section details the implementation requirements for the
Association Control Service Element (ACSE) of the Application
layer. It is the intent of this section to follow the ISO ACSE
standards. Where those specifications are inadequate, this
section should provide the necessary information.
5.5.2 Services
5.5.2.1 ACSE Services
The following ACSE service primitives are within the
possible scope of an NBS conformant system:
1. A_ASSOCIATE request
2. A_ASSOCIATE indication
3. A_ASSOCIATE response
4. A_ASSOCIATE confirm
5. A_RELEASE request
6. A_RELEASE indication
7. A_RELEASE response
8. A_RELEASE confirm
9. A_ABORT request
10. A_ABORT indication
11. A_P_ABORT indication
5.5.2.2 Use of Presentation Layer Services
ACSE services will make use of Presentation layer services
in the manner defined in the ACSE Protocol specification.
5.5.3 Protocol agreements
Implementations shall be based on the ACSE Service definition and
the ACSE Protocol specification.
5.5.3.1 Application Context
Specific Application Contexts and their names will be
supplied and defined by an appropriate NBS SIG. Other
application contexts may be defined and specified as
dictated by particular application requirements.
Optional names and specifications are outlined by each
application SIG under the heading "Specific ASE
Requirements for ACSE, Presentation, and Session". The use
of these names implies adherence to the relevant NBS
implementors' agreements for a particular application SIG.
The utility of an NBS defined name (which is an OBJECT
IDENTIFIER) is left up to the application. An NBS name may
or may not be used in the ACSE APDU. The consequence of the
name is left up to the application entities and any a priori
agreements that they have. In other words, it is up to the
application whether this parameter is ignored or validated
for correctness. (Note that the consequence of this name
must also be dictated by the particular conformance test).
The UL SIG recognizes that this parameter needs further
definition by the appropriate standards bodies. Therefore,
the use of this parameter for association negotiation is not
recommended at this time.
5.5.3.2 Section Deleted
5.5.3.3 AE Title
A value is defined for the AE Title only to satisfy the FTAM
requirement for exchanging fields of this type.
This value does not identify an Application Entity and
carries no semantics. The AE title maps onto the AP title
and the AE qualifier. If the AE title is used, then both QP
title (an OBJECT IDENTIFIER) and AE qualifier (an INTEGER)
must be sent.
The value for the AP titles is {1 3 999 1 ftam-nil-ap-title
(7)} at this time. Values for the AE qualifier are outside
the scope of these agreements.
5.6 PRESENTATION
5.6.1 Introduction
This section details the implementation requirements for the
Presentation layer. It is the intent of this section to follow
the ISO Presentation Standards. Where those specifications are
inadequate, this section should provide the necessary
information.
The task of the Presentation layer is to carry out the
negotiation of transfer syntaxes and to provide for the
transformation to and from transfer syntaxes. The transformation
to and from a particular transfer syntax is a local
implementation issue and is not discussed within this section.
This section is concerned with the protocol agreements, and thus
is entirely devoted to the issues involved with the negotiation
of transfer syntaxes and the responsibilities of the
Presentation protocol.
5.6.2 Services
5.6.2.1 Presentation Services
The following functional units are within the possible scope
of an NBS conformant system:
Presentation Kernel - This functional
unit supports the basic Presentation
services required to establish a
Presentation connection, transfer
normal data, and release a
Presentation connection. This is a
non-negotiable functional unit.
The Context Management and Context
Restoration functional units are not
within the scope of an NBS
conformant system and need not be
supported.
The requirement that the Presentation kernel functional unit
be implemented does not imply that any of the Session
functional units for expedited data, typed data, and
capability data and the corresponding Presentation service
primitives are required to be implemented. Any service not
supported by the Session layer is also not supported by the
Presentation layer; see the section on Session Functional
Units for the possible Session functional units. The
services provided by the Presentation layer are limited by
the services provided by the Session layer as defined in the
Session service definition ISO/IS 8326 and the Session
protocol definition ISO/IS 8327.
5.6.2.2 Use of Session Layer Services
Presentation layer services shall make use of Session layer
services in the manner defined in the Presentation Protocol
Specification.
5.6.3 Protocol Agreements
Implementations shall be based on the Presentation Service
Definition, ISO 8822 and the Presentation Protocol Definition,
ISO 8823.
5.6.3.1 Transfer Syntaxes
o The following transfer syntax must be supported
for all mandatory abstract syntaxes: the basic
encoding rules for ASN.1. This syntax is derived
by applying the basic encoding rules for ASN.1 to
the abstract syntax (see the Basic Encoding Rules
for ASN.1, ISO 8825).
o The number of transfer syntaxes proposed is
dependent upon the recognized transfer syntaxes
which are available to support the particular
abstract syntaxes used by an Application Entity.
5.6.3.2 Abstract Syntaxes
o Several abstract syntax names may map onto a
single transfer syntax name.
o The ACSE abstract syntax shall always be present
in the defined context set.
5.6.3.3 Presentation Context Identifier
o The presentation context identifier value shall be
encoded in no more than 2 octets.
o Implementations must be able to handle a minimum
of 2 presentation contexts per connection.
5.6.3.4 Mode-selector Position in SET
Whenever the Mode-selector value within either a CP-PPDU or
CPA-PPDU is normal-mode (1), it shall occur as the first
element within the SET.
5.6.3.5 Default Context
If the Presentation expedited data service is required, the
default context must be explicitly present in the P-CONNECT
PPDU at Presentation connect time.
5.6.3.6 P-Selectors
Local P-selectors shall be a maximum of 4 octets. This
applies only to P-selectors in PPDUs whose receipt by an
NBS-conformant system normally results in either a P-CONNECT
indication or a P-CONNECT confirmation being issued.
5.6.3.7 Provider Abort Parameters
No conformance requirements are implied by the use of either
the Abort-reason or the Event-identifier component of the
ARP-PPDU. The decision to include these parameters is left
up to the implementation issuing the abort.
5.6.3.8 Provider Aborts and Session Version
The Presentation Provider Abort PPDU (ARP-PPDU) shall be
present regardless of the Session version in effect for a
given association. This precludes the use of indefinite
length encoding of an ARP-PPDU when Session version 1 is in
effect.
5.6.3.9 CPC-type
NBS conformant implementations shall not use any CPC-type
values in the SS-user data parameter of the S-CONNECT
request unless more than one transfer syntax is proposed.
Each CPC-type represents a unique transfer syntax. Note:
currently only 1 transfer syntax is recognized.
5.6.3.10 Presentation-context-definition-result-list
No semantics are implied by the absence of this optional
component of the CPR-PPDU. This component is required if
the Provider-reason is absent in the CPR-PPDU. If the
Provider-reason is present, then the Presentation-context-
definition-result-list is optional.
5.6.3.11 RS-PPDU
The Presentation-context-identifier-list shall not be
present when only the kernel functional unit is in effect.
5.6.4 Presentation ASN.1 Encoding Rules
5.6.4.1 Invalid Encoding
If a received PPDU contains any improperly encoded data
values (including data values embedded within the User Data
field of a PPDU) and an abort is issued, then either a P-U-
ABORT or a P-P-ABORT shall be issued.
5.6.4.2 Protocol-version, Presentation-requirements
Protocol-version and Presentation-requirements shall be
encoded in their primitive forms, if present.
5.6.4.3 Presentation-selector
Any type defined as a Presentation-selector shall be encoded
in its primitive form, if present.
5.7 SESSION
5.7.1 Introduction
This section details the implementation requirements for the
Session layer. It is the intent of this section to follow the
ISO Session Standards to the fullest extent possible. Where
those specifications are inadequate, this section should provide
the necessary information.
5.7.2 Services
5.7.2.1 Session Services
The following functional units are within the possible scope
of an NBS conformant system:
Kernel
Duplex
Expedited Data
Resynchronize
Exceptions
Activity Management
Half-duplex
Minor Synchronize
Major Synchronize
Typed Data
5.7.2.2 Use of Transport Services
The use of Transport layer services by the Session layer
functional units listed in the previous section is as
specified in the Transport Protocol Specification, ISO/IS
8073.
5.7.3 Protocol Agreements
Implementations shall be based on the Session service definition
ISO/IS 8326 and the Session protocol definition ISO/IS 8327.
5.7.3.1 Concatenation
When a category 0 SPDU is concatenated with a category 2
SPDU, the category 0 SPDU shall contain neither the Token
Item field nor User Data. If either a Token Item field or
User Data is received in such a concatenated incoming SPDU,
the receiving Session Protocol Machine has the option of
either properly processing the fields or issuing a provider
abort on the connection.
Extended concatenation is not required and can be refused
using the normal negotiation mechanisms of the Session
protocol.
5.7.3.2 Segmenting
Session Segmenting is not required and can be refused using
the normal negotiation mechanisms of the session protocol.
5.7.3.3 Reuse of Transport Connection
Reuse of a transport connection is not required and can be
refused.
5.7.3.4 Use of Transport Expedited Data
The use of transport expedited service is as stated in the
session protocol specification: if available, transport
expedited service must be used.
5.7.3.5 Use of Session Version Number
Session versions 1 and 2 are recognized. Each relevant NBS
SIG chooses the version or versions of Session which it
requires for a particular implementation phase, and these
choices are documented in section 5.9.1.
Session version 2 specifies the use of unlimited user data
during connection establishment as dictated by the DAD 2 to
ISO 8327 to Incorporate Unlimited User Data.
All Session version 1 implementations must be able to
negotiate version 1 operation when responding to a CONNECT
(CN) SPDU proposing both version 1 and version 2.
In addition, all Session version 1 implementations, upon
receipt of a CONNECT (CN) SPDU proposing only version 2,
should respond with a REFUSE (RF) SPDU containing a Reason
Code indicating that the proposed version is not supported.
Until pending defect reports are adopted, implementations
may disconnect.
If Session versions 1 and 2 are both proposed in the CONNECT
(CN) SPDU, then the maximum length of the User Data
parameter value in the CONNECT (CN) SPDU shall be 512 octets
and a PGI field of 193 shall be associated with this
parameter. This implies that an implementation supporting
both Session versions 1 and 2 can establish a connection
with an implementation supporting only version 1.
If only Session version 2 is proposed in the CONNECT (CN)
SPDU, then the maximum length of the Session User Data
parameter value of the S-CONNECT service request shall be
10,240 octets. This restriction implies that the OVERFLOW
ACCEPT (OA) SPDU and CONNECT DATA OVERFLOW (CDO) SPDU are
not used. If the length of the User Data parameter value is
no greater than 512 octets, then an associated PGI field of
193 shall be used, otherwise a PGI field of 194 shall be
used.
When Session version 2 is negotiated, then in all SPDUs the
maximum length of the User Data parameter value with an
associated PGI field of 193 shall be 10,240 octets. NBS
conformant Session version 2 implementations need only
support the maximum data lengths specified in the Specific
ASE Requirements section.
5.7.3.6 Receipt of Invalid SPDUs
Upon receipt of an invalid SPDU, the SPM shall take any
action in A.4.3 of the Session protocol definition ISO/IS
8327 except action d.
5.7.3.7 Invalid SPM Intersections
If the conditions described in A.4.1.2 of the Session
protocol definition ISO/IS 8327 are satisfied, the SPM shall
always take the actions described by A.4.1.2 a.
Note: This implies that no S-P-EXCEPTION-REPORT
indications will be generated nor EXCEPTION REPORT
SPDUs sent due to invalid intersections of the
Session state table resulting from received SPDUs.
5.7.3.8 S-Selectors
S-selectors shall be a maximum of 16 octets.
5.8 Universal ASN.1 Encoding Rules
5.8.1 Tags
The maximum value of an ASN.1 basic encoding tag that need be
handled by an NBS-conformant implementation shall be 16,383.
This is the maximum unsigned number that can be represented in 14
bits, therefore, the maximum encoding of a tag occupies 3 octets.
5.8.2 Definite length
The maximum value of an ASN.1 length octets component that need
be handled by an NBS-conformant implementation shall be
4,294,967,295. This is the maximum unsigned integer that can be
represented in 32 bits, therefore, the maximum encoding of a
length octets component will occupy 5 octets. Also, note this
restriction does not apply to indefinite length encoding.
5.8.3 EXTERNAL Type
It is assumed that "presentation layer negotiation of encoding
rules" is always in effect, and therefore clause 32.5 of the
Specification of ASN.1, ISO 8824 never applies.
5.9 CONFORMANCE
In order for an implementation to be in conformance with the NBS
implementors' agreements, the following rules shall be adhered to:
o A conformant implementation must meet all of the requirements of
this specification. All documents referenced in the Upper Layers
section shall be used as the supporting documents for all
implementations of ACSE, Presentation, or Session. The full
references for these documents are in the REFERENCES section.
o NBS conformant implementations shall be ISO conformant. PICS may
contain limitations on length or value aspects of a protocol.
PICS of NBS conformant systems shall not contain restrictions
more severe than those in these implementation agreements. Note:
an implementation may abort a connection if the constraints
specified in these agreements are violated.
o Guidelines for implementation of standards' defects will be as
per the resolution of such defects by the appropriate ISO
standards committee.
5.9.1 Specific ASE Requirements for ACSE Presentation and
Session
The following list for each ASE the corresponding NBS SIGs
requirements of and restrictions on ACSE, Presentation, and
Session.
All listed requirements and restrictions shall be included in an
NBS conformant system and shall be implemented in accordance with
these NBS Implementor's agreements.
All OBJECT IDENTIFIERS are specified in terms of their associated
ObjectDescriptor's. See the chapter on OBJECT IDENTIFIERs for
the values of the associated OBJECT IDENTIFIERs.
5.9.1.1 FTAM
5.9.1.1.1 Phase 2
ACSE Requirements:
all
Application Contexts:
o "ISO FTAM" - implies the use of the
ACSE and the FTAM ASE.
Abstract Syntaxes:
o "ISO 8650-ACSE1"
Associated Transfer Syntax:
o "Basic Encoding of a
single ASN.1 type"
Presentation Requirements:
Presentation Functional Units:
o kernel
Presentation Contexts:
o At least 3 Presentation Contexts
must be supported.
Abstract Syntaxes:
Abstract Syntaxes for conformant
Implementations
o "FTAM-PCI"
Associated Transfer Syntax:
o "Basic Encoding of a
single ASN.1 type:
o "FTAM unstructured binary abstract
syntax"
Associated Transfer Syntax:
o "Basic Encoding of a
single ASN.1 type"
Abstract Syntaxes Depending on
Implementation Profile
o "FTAM-FADU"
Associated Transfer Syntax:
o "Basic Encoding of a
single ASN.1 type"
o "FTAM unstructured text abstract
syntax"
Associated Transfer Syntax:
o "Basic Encoding of a
single ASN.1 type"
o "NBS abstract syntax AS1"
Associated Transfer Syntax:
o "Basic Encoding of a
single ASN.1 type"
o "NBS file directory entry abstract
syntax"
Associated Transfer Syntax:
o "Basic Encoding of a
single Asn.1 type"
Session Requirements:
Session Functional Units:
o kernel
o duplex
Version Number: 2
Maximum size of User Data parameter field:
10,240
Session Options:
Session Functional Units:
o resynchronize
only a Resynchronize Type
value of "abandon"
o minor synchronize
Note: The minor
synchronize
functional unit is
required whenever
the resynchronize
functional unit is
available.
5.9.1.2 MHS
5.9.1.2.1 Phase 1
Session Requirements:
Session Functional Units:
o kernel
o half-duplex
o exceptions
o activity management
o minor synchronize
Version Number: 1
Maximum size of User Data parameter field:
512
Session Notes:
o Restricted use is made by the RTS
of the session services implied by
the functional units selected.
Specifically,
. No use is made of S-TOKEN-
GIVE, and
. S-PLEASE-TOKENS only asks for
the data token.
o In the S-CONNECT SPDU, the Initial
Serial Number should not be
present.
o The format of the Connection
Identifier in the S-CONNECT SPDU is
described in Version 5 of the
X.400-Series Implementors' Guide.
5.9.1.3 DS
5.9.1.3.1 Phase 1
ACSE Requirements:
all
Application Context:
Abstract Syntaxes:
o "ISO 8650-ACSE1"
Associated Transfer Syntax:
o "Basic Encoding of a
single ASN.1 type"
o "Directory Services"
Associated Transfer Syntax:
o "Basic Encoding of a
single ASN.1 type"
Presentation Requirements:
Presentation Functional Units:
o kernel
Presentation Contexts:
o At least 2 Presentation Contexts
must be supported.
Session Requirements:
Session Functional Units:
o kernel
o duplex
Version Number: 2
Maximum size of User Data parameter field:
10,240
5.10 APPENDIX A: RECOMMENDED PRACTICES
Reflect Parameter Values
The optional "Reflect Parameter Values" parameter in the provider
ABORT SPDU shall be encoded so as to represent the Session connection
state, the incoming event and the first invalid SPDU field exactly at
the moment a protocol error was detected.
The first octet encodes the Session state as a number relative to 0 as
detailed in Table 1.
The second octet encodes the incoming event as a number relative to 0
as detailed in Table 2.
The third octet contains the SI, PGI, or PI Code of any SI field, PGI
unit or PI unit in error.
NOTE: The remaining 6 octets are undefined herein.
Table 1 - Session States
State rel.# Description
1 0 Idle, no transport connection
1B 1 Wait for T-connect confirm
1C 2 Idle, transport connected
2A 3 Wait for the ACCEPT SPDU
3 4 Wait for the DISCONNECT SPDU
8 5 Wait for the S-CONNECT response
9 6 Wait for the S-RELEASE response
16 7 Wait for the T-DISCONNECT indication
713 8 Data Transfer state
1A 9 Wait for the ABORT ACCEPT SPDU
4A 10 Wait for the MAJOR SYNC ACK SPDU or PREPARE
SPDU
4B 11 Wait for the ACTIVITY END ACK SPDU or PREPARE
SPDU
5A 12 Wait for the RESYNCHRONIZE ACK SPDU or PREPARE
SPDU
5B 13 Wait for the ACTIVITY INTERRUPT SPDU or PREPARE
SPDU
5C 14 Wait for the ACTIVITY DISCARD ACK SPDU or
PREPARE
SPDU
6 15 Wait for the RESYNCHRONIZE SPDU or PREPARE
SPDU
10A 16 Wait for the S-SYNC-MAJOR response
10B 17 Wait for the S-ACTIVITY-END response
11A 18 Wait for the S-RESYNCHRONIZE response
11B 19 Wait for the S-ACTIVITY-INTERRUPT response
11C 20 Wait for the S-ACTIVITY-DISCARD response
15A 21 After PREPARE, wait for the MAJOR SYNC ACK SPDU or the
ACTIVITY END ACK
15B 22 After PREPARE, wait for the RESYNCHRONIZE SPDU or the
ACTIVITY DISCARD SPDU
15C 23 After PREPARE, wait for the RESYNCHRONIZE ACK SPDU, or
the ACTIVITY INTERRUPT ACK SPDU or the ACTIVITY
DISCARD ACK SPDU
18 24 Wait for GIVE TOKENS ACK SPDU
19 25 Wait for a recovery request or SPDU
20 26 Wait for a recovery SPDU or request
21 27 Wait for the CAPABILITY DATA ACK SPDU
22 28 Wait for the S-CAPABILITY-DATA response
1D 29 Wait for the CONNECT DATA OVERFLOW SPDU
2B 30 Wait for the OVERFLOW ACCEPT SPDU
15D 31 After PREPARE, wait for the ABORT SPDU
Table 2 - Incoming Events
Event Rel.# Description
SCONreq 0 S-CONNECT request
SCONrsp+ 1 S-CONNECT accept response
SCONrsp- 2 S-CONNECT reject response
SDTreq 3 S-DATA request
SRELreq 4 S-RELEASE request
SRELrsp+ 5 S-RELEASE accept response
SUABreq 6 S-U-ABORT request
TCONcnf 7 T-CONNECT confirmation
TCONind 8 T-CONNECT indication
TDISind 9 T-DISCONNECT indication
TIM 10 Time out
AA 11 ABORT ACCEPT
AB-nr 12 ABORT - no reuse
AC 13 ACCEPT
CN 14 CONNECT
DN 15 DISCONNECT
DT 16 DATA TRANSFER
FN-nr 17 FINISH - no reuse
RF-nr 18 REFUSE - no reuse
SACTDreq 19 S-ACTIVITY-DISCARD request
SACTDrsp 20 S-ACTIVITY-DISCARD response
SACTEreq 21 S-ACTIVITY-END request
SACTErsp 22 S-ACTIVITY-END response
SACTIreq 23 S-ACTIVITY-INTERRUPT request
SACTIrsp 24 S-ACTIVITY-INTERRUPT response
SACTRreq 25 S-ACTIVITY-RESUME request
SACTSreq 26 S-ACTIVITY-START request
SCDreq 27 S-CAPABILITY-DATA request
SCDrsp 28 S-CAPABILITY-DATA response
SCGreq 29 S-CONTROL-GIVE request
SEXreq 30 S-EXPEDITED-DATA request
SGTreq 31 S-TOKEN-GIVE request
SPTreq 32 S-TOKEN-PLEASE request
SRELrsp- 33 S-RELEASE response reject
SRSYNreq(a) 34 S-RESYNCHRONIZE request abandon
SRSYNreq(r) 35 S-RESYNCHRONIZE request restart
SRSYNreq(s) 36 S-RESYNCHRONIZE request set
SRSYNrsp 37 S-RESYNCHRONIZE response
SSYNMreq 38 S-SYNC-MAJOR request
SSYNMrsp 39 S-SYNC-MAJOR response
SSYNmreq 40 S-SYNC-MINOR request
SSYNmrsp 41 S-SYNC-MINOR response
STDreq 42 S-TYPED-DATA request
SUERreq 43 S-U-EXCEPTION-REPORT request
AB-r 44 ABORT - reuse SPDU
Table 2 - continued
Event Rel.# Description
AD 45 ACTIVITY DISCARD SPDU
ADA 46 ACTIVITY DISCARD ACK SPDU
AE 47 ACTIVITY END SPDU
AEA 48 ACTIVITY END ACK SPDU
AI 49 ACTIVITY INTERRUPT SPDU
AIA 50 ACTIVITY INTERRUPT ACK SPDU
AR 51 ACTIVITY RESUME SPDU
AS 52 ACTIVITY START SPDU
CD 53 CAPABILITY DATA SPDU
CDA 54 CAPABILITY DATA ACK SPDU
ED 55 EXCEPTION DATA SPDU
ER 56 EXCEPTION REPORT SPDU
EX 57 EXPEDITED DATA SPDU
FN-r 58 FINISH - reuse SPDU
GT 59 GIVE TOKENS SPDU
GTA 60 GIVE TOKENS ACK SPDU
GTC 61 GIVE TOKENS CONFIRM SPDU
MAA 62 MAJOR SYNC ACK SPDU
MAP 63 MAJOR SYNC POINT SPDU
MIA 64 MAJOR SYNC ACK SPDU
MIP 65 MINOR SYNC POINT SPDU
NF 66 NOT FINISHED SPDU
PR-MAA 67 PREPARE (MAJOR SYNC ACK) SPDU
PR-RA 68 PREPARE (RESYNCHRONIZE ACK) SPDU
PR-RS 69 PREPARE (RESYNCHRONIZE) SPDU
PT 70 PLEASE TOKENS SPDU with Token Item
Parameter
RA 71 RESYNCHRONIZE ACK SPDU
RF-r 72 REFUSE - reuse SPDU
RS-a 73 RESYNCHRONIZE - abandon SPDU
RS-r 74 RESYNCHRONIZE - restart SPDU
RS-s 75 RESYNCHRONIZE - set SPDU
TD 76 TYPED DATA SPDU
CDO 77 CONNECT DATA OVERFLOW SPDU
OA 78 OVERFLOW ACCEPT SPDU
PR-AB 79 PREPARE (ABORT) SPDU6. ISO FILE TRANSFER, ACCESS AND MANAGEMENT PHASE 2
6.1 INTRODUCTION
This section defines Implementors' Agreements based on ISO File
Transfer, Access and Management (FTAM), as defined in ISO 8571. This
International Standard has four parts. Part 1 of the IS gives general
concepts, Part 2 defines the Virtual Filestore (VFS), Part 3 defines
the File Service, and Part 4 defines the File Protocol.
FTAM, as described in the IS, is based on the following ISO documents:
ACSE Service and Protocol (ISO 8649, ISO 8650), Presentation Service
and Protocol (ISO 8822, ISO 8823), ASN.1 Abstract Syntax Notation and
Basic Encoding Rules (ISO 8824, ISO 8825), and Session Service and
Protocol (ISO 8326, ISO 8327). These services and protocols are
defined architecturally in the OSI Reference Model (ISO 7498). These
Agreements provide detailed guidance for the implementor, and
eliminate ambiguities in interpretations.
The general agreements reached with respect to the ISO File Transfer,
Access and Management Protocol (FTAM) are that the Phase 2 FTAM
specification (this section) is based on the International Standard
(IS).
6.2 SCOPE AND FIELD OF APPLICATION
These FTAM Phase 2 Agreements cover transfer of and access to files
between the Filestores of two end systems, including the management of
a Virtual Filestore. One end system acts in the Initiator role and
initiates the file transfer/access, while the other end system acts in
the Responder role and provides access to the file in the Virtual
Filestore. This paper describes Agreements for the actions and
attributes of the Virtual Filestore, and the service provided by the
file service provider to file service users, together with the
necessary communications between the Initiator and Responder.
ZDDDDDDDDDDDDDD?
3 Virtual 3
3 Filestore 3
3 2 3
@DDDDDDRDDDDDDDY
:
:
ZDDDDDDDDDDDDDD? ZDDDDDDDDDDDDDD? ZDDDDDDPDDDDDDD? ZDDDDDDDDDDDDDD?
3 Real 3 3 End 3 3 End 3 3 Real 3
3 Filestore CDDDD4 System 1 FMMMM5 System 2 CDDDD4 Filestore 3
3 1 3 3- Initiator - 3 3- Responder - 3 3 2 3
@DDDDDDDDDDDDDDY @DDDDDDDDDDDDDDY @DDDDDDDDDDDDDDY @DDDDDDDDDDDDDDY
Figure 6.1 Model of file transfer/access
Note: Agreements apply on the double lines of Figure 1.
The mapping between the Virtual Filestore and the Real Filestore
together with the local data management system is not part of
these Agreements.
These Agreements define General Agreements is in section 6.5 through
6.16, minimum functionality (Conformant Implementations) in section
6.17, and functionality for several Implementation Profiles which are
tailored to different classes of user requirements in sections 6.18
and 6.19.
6.3 STATUS
This version of the FTAM Implementation Agreements was completed
December 18, 1987. No further enhancements will be made to this
version. See the next section, ERRATA.
Note: These Agreements were updated from the previous March 1987 DIS
based Agreements.
6.4 ERRATA
ZDDDDDDDDDDDBDDDDDDDDDBDDDDDDDDDDDBDDDDDDDDDDDBDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3CP no 3Type 3ref. doc 3section 3Comment 3
CDDDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3CP 2/88-1 3technical3NBS 500-15036.10.2.2, 3Check of already established presentation 3
3 3 3 36.10.2.3 3context for a document type not at CREATE time 3
3 3 3 3 3but at OPEN time 3
CDDDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3CP 2/88-2 3editorial3NBS 500-15036, App. A, 3Appendix A, Part 4 of Object Identifiers 3
3 3 3 3Part 4 3removed 3
CDDDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3CP 2/88-3 3editorial3NBS 500-15036.5 3Clarification that current AET definition 3
3 3 3 3new bullet 3carries no semantics and other values are 3
3 3 3 37 3outside scope. 3
CDDDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3CP 2/88-4 3technical3NBS 500-15035.9 3Clarification for UL specs that ABORT possible 3
3 3 3 3 3if UL constraints are violated 3
CDDDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3CP 2/88-5 3editorial3NBS 500-15036, App. A 3Replace 'organ-code' by 'organization-code' for3
3 3 3 3 3all NBS Object Identifiers 3
CDDDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3CP 2/88-6 3editorial3NBS 500-15036.5 3Clarification that <shared ASE information> 3
3 3 3 3new bullet 3and <application context name> agreements are 3
3 3 3 38,9 3general agreements 3
3 3 3 36.18.3 3 3
CDDDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3CP 2/88-7 3editorial3NBS 500-15036.18.2 3Move 6.18.2 to new Section 6.17.9 3
CDDDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3CP 2/88-8 3editorial3NBS 500-1503Table 6.4 3Rendition of currency sign in table 6.4 3
CDDDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3CP 2/88-9 3editorial3NBS 500-15036.2, 6.17 3Clarification of meaning of General Agreements,3
3 3 3 3 3Conformance and Implementation Profiles 3
CDDDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3CP 2/88-10 3editorial3NBS 500-15036.5 3Definition of 's', 'os' for a parameter. 3
3 3 3 3new bullet 3Clarification of support level for <initiator 3
3 3 3 310, 6.18.3 3identity>, <filestore password>, <access 3
3 3 3 3bullet 5 3password> parameter 3
3 3 3 36.16.1 3 3
3 3 3 36.16.2 3 3
CDDDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3CP 5/88-1 3editorial3NBS 500-1503Table 6.7 3Clarification fo support of T&M service class 3
3 3 3 3Note 4 3 3
CDDDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3CP 5/88-2 3editorial3NBS 500-15036.18.3 3Remove <charging> value zero 3
3 3 3 3bullet 6 3 3
CDDDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3CP 5/88-3 3editorial3NBS 500-1503Table 6.9 3Updated definition of Datatype 2 3
CDDDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3CP 5/88-4 3editorial3NBS 500-15036.5, new 3More clarification to CP 2/88, use of AETitle 3
3 3 3 3bullet 7 3values 3
@DDDDDDDDDDDADDDDDDDDDADDDDDDDDDDDADDDDDDDDDDDADDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
6.5 ASSUMPTIONS
1. FTAM protocol machines must be able to parse and process at a
minimum 7K octets of FTAM PCI and FTAM user data (including
grouped FPDUs) as they would be encoded with the ASN.1 Basic
Encoding Rules. It is recommended, however, that Presentation
user data not be restricted in size.
2. In order to maximize interoperability, it is important that the
implementations of FTAM service providers do not unnecessarily
restrict the service user's ability to generate arbitrary file
service requests. Otherwise, they may not be able to work with
FTAM Responders whose operation is constrained by their mapping
of the FTAM Virtual Filestore to their local filestore. For
example, error procedures should only be invoked when an error
actually occurs, not at the point of the specification of
options which might result in an error.
3. Implementations must be able to parse all valid optional
parameters if they are present in the PDU. Only those optional
parameters specified as supported in these Agreements are
required to be implemented. If these parameters are not present,
a default value is assigned locally. A Responder should not
refuse a request solely because a parameter that is optional in
the FTAM standard, but is supported in these Agreements, is not
present.
4. Consideration of any standardized service interface is not
covered by these Agreements.
5. These Agreements define no restrictions for the values used for
the <communication quality of service> parameter in <F-
INITIALIZE>.
6. FTAM is defined in phases. The Phase 1 FTAM implementation
specification is based on the second ISO Draft Proposal, dated
April 1985, and the ISO Draft Proposal 8824 and 8825.
The Phase 2 FTAM specification (this section) is based on the
International Standard (IS). THERE IS NO BACKWARD COMPATIBILITY
WITH NBS FTAM PHASE 1. Backward compatibility is impossible,
since Phase 1 uses Session services directly, while Phase 2 uses
ACSE and Presentation services. Furthermore, there are
differences in Filestore, PDU Abstract Syntax, FADU Abstract
Syntax, and Transfer Syntax. There also are differences in the
transparency mechanisms and service class negotiations.
The <implementation information> parameter of <F-INITIALIZE> FPDU
as defined in ISO 8571-4, 20.3 is used to pass 'user version'
information with respect to different FTAM phases of the NBS
Implementors Agreements or with respect to FTAM profiles of other
bodies (see section 6.13 6.12 of this document). It is the goal
of these Agreements to use the 'user version' mechanism to
provide at least one level of backward compatibility for all
future NBS FTAM Phases, facilitating backward compatibility for
future FTAM products, assuming different new versions of the
respective IS's also enable backward compatibility.
7. Section 5.5.3 5.5.3.3 defines a value (that carries no semantics)
for the AETitle that can be used by FTAM ASEs for communication.
Other values for the AETitle are outside the scope of these
Agreements.
For the Called-AETitle, Calling-AETtitle and Responding AETitle
the association shall not be rejected/aborted if the value
specified in 5.5.3.3 is sent or if any of the parameters are not
sent. The association may be rejected/aborted if a value other
than specified in 5.5.3.3 is sent.
Use of values outside the scope of these Agreements is
discouraged until agreed upon semantics have been associated with
AETitles.
8. Use of <shared ASE information> parameter and <charging>
parameter is not defined within the scope of the Agreements.
9. Use of <application context name> parameter is not defined within
the scope of these Agreements. This parameter does not prohibit
the establishment of an FTAM association.
10. These Agreements use the term 'supported' for a parameter to mean
that the syntax and semantics of that parameter shall be
implemented. However, it is not a requirement that the parameter
be used in all instances of communication, unless stated
otherwise.
Also these Agreements use the term 'optionally supported' for a
parameter to mean that it is left to the implementation whether
the semantics of that parameter are implemented or not.
6.6 PRESENTATION AGREEMENTS
The following Abstract Syntaxes are recognized in these agreements:
"FTAM FADU"
"FTAM PCI"
"FTAM unstructured text abstract syntax"
"FTAM unstructured binary abstract syntax"
"NBS abstract syntax AS1"
"NBS file directory entry abstract syntax"
The following Transfer Syntax is supported:
"Basic Encoding of a single ASN.1 type"
(See Appendix A, Part 3)
6.7 SERVICE CLASS AGREEMENTS
Implementation Agreements have been reached for the following service
classes.
o File Transfer
o File Access
o File Management
o File Transfer and Management
o Unconstrained
6.8 FUNCTIONAL UNIT AGREEMENTS
Implementation agreements have been reached for the following
functional units.
o Kernel
o Read
o Write
o File Access
o Limited File Management
o Enhanced File Management
o Grouping
Implementation of the Recovery, Restart Data Transfer, and FADU
Locking functional units is not specified.
6.9 FILE ATTRIBUTE AGREEMENTS
Implementation of the Kernel Group of file attributes is defined. If
the optional Storage Group and Security Group are implemented, aspects
of their implementation are defined. Implementation of the Private
Group is not specified.
Responses to an attribute value request shall always include one of
the following (as specified in ISO 8571-2, clause 9.4):
o An actual file attribute value.
o A value indicating that no value is available, optionally with a
diagnostic.
o No value and an error code, optionally with a diagnostic
indicating that the attribute is not supported.
6.9.1 Mandatory Group
Only the Kernel Group of attributes is required. A value for
<filename>, <permitted actions>, and <contents type> will always
be available.
A minimum range is required for <filename> values as specified in
ISO 8571-2. No maximum length or format restrictions apply. A
system that does not support <filename> values with a sequence of
more than one Graphic String or extended <filename>
characteristics may reject a request involving such a <filename>.
All systems must be able to interpret a <filename> value with a
sequence of one Graphic String. Requests using such a single
component <filename> value with a sequence of one Graphic String
are responded to using a single component <filename> value.
Responses to requests involving <filename> values having two or
more Graphic Strings are not defined here but may be interpreted
via bilateral or other external agreements. Use of <filename>
values with a sequence of more than one Graphic String is
discouraged.
Apart from the minimum conformance requirements specified in ISO
8571-2, file names have to be specified in the naming convention
of the responding FTAM implementation. It is a local
implementation matter of the FTAM Responder, whether or not an
additional name mapping onto the real FIlestore's file name
convention is supported.
In order to enable interworking with all FTAM Responders' virtual
Filestores, it is recommended that FTAM Initiators impose no
restrictions on the attribute range supported for file names
beyond those specified in ISO 8571-2.
For the purpose of interworking according to these Agreements the
<contents type> attribute is limited to the <document type name>
format. The <constraint set name, abstract syntax name> form is
outside the scope of these Agreements. It should always be
parsed correctly when received, but may result in an error.
6.9.2 Optional Groups
If the optional Security Group of file attributes is implemented,
an actual value must be available for the <access control>
attribute.
The <access control> attribute is a SET OF <access control
element>. The minimum requirement in these Agreements is the
support of one <access control element>, according to the base
standard. The terms <concurrency access>, <identity>, and
<passwords> are each optionally supported. Details of their use
shall be specified in the PICS. Use of the <location> term is
not specified in these Agreements.
Implementation of the Private Group is not specified.
6.10 DOCUMENT TYPE AGREEMENTS
These document types are defined.
FTAM-1 "ISO FTAM unstructured text"
FTAM-2 "ISO FTAM sequential text"
FTAM-3 "ISO FTAM unstructured binary"
NBS-6 "NBS-6 FTAM sequential file"
NBS-7 "NBS-7 FTAM random access file"
NBS-8 "NBS-8 FTAM indexed file"
NBS-9 "NBS-9 FTAM file directory file"
Detailed document type definitions are given in Appendix 6A and in ISO
8571-2, Annex B.
Note: Document types NBS-1 to NBS-5 are not defined in these
Agreements. The numbering starts with NBS-6 because of the original
DIS version of these Agreements.
An implementation claiming conformance to these Agreements which also
supports any or all of the document types FTAM-1, FTAM-2, and FTAM-3
as defined in ISO 8571-2, Annex B, must minimally support the
combinations of parameter values as specified in Table 6.1.
Table 6.1 Parameters for FTAM-1, -2, -3
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 Universal Maximum String 3
3 Class Number String Length6 Significance 3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3 3
3 FTAM-1 General String 1(27) 134 or less 'not-significant'3
3 IA5String 2(22) 3
3 3
3 FTAM-2 Graphic String 3,4(25) 134 or less5 'not-significant'3
3 3
3 3
3 FTAM-3 <not applicable> 512 or less 'not-significant43
3 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
Notes:
1. The minimum level of support for General String is the IA5 G0
character set and the 8859-1 G0 and G1 character sets, and IA5 C0
set.
2. The support for IA5 String is the IA5 G0 character set and the
IA5 C0 set.
3. The minimum level of support for Graphic String is the IA5 G0
character set and the 8859-1 G0 and G1 sets.
4. This is the default when the parameter is not specified.
5. The implementation need not support Data Units whose total
character count exceeds 134.
6. As per Table 6.3.
For the use of FTAM-2 only the FADU identities of 'begin', 'end',
'first', and 'next' are required for conformant implementations.
For the document types NBS-6, NBS-7 and NBS-8 parameters are used for
which the Agreements apply as specified in Table 6.2.
Table 6.2 Parameters for NBS-6, NBS-7, NBS-8
ZDDDDDDDDDDDDDDBDDDDDDDDDDDDDBDDDDDDDDDDDDDDDDDDDDDDDBDDDDDDDDDDDDDDDDDBDDDDDDDDDDDDDDDDD?
3 Parameter 3 PrimType 3 String-length 3 Length-1 3 Length-2 3
CDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDD4
3 3 3 3 3 3
3 int 3 INTEGER 3 Number of octets 3 3 3
3 3 3 required to represent,3 3 3
3 3 3 in 2's complement 3 3 3
3 3 3 format, the largest 3 3 3
3 3 3 integer to be passed 3 3 3
3 3 3 3 3 3
3 bit 3 BIT STRING 3 Number of bits in 3 3 3
3 3 3 string 3 3 3
3 3 3 (non-varying) 3 3 3
3 3 3 3 3 3
3 ia5 3 IA5String 3 Max number of 3 3 3
3 3 3 characters in string 3 3 3
3 3 3 3 3 3
3 graphic 3 Graphic 3 Max number of 3 3 3
3 3 String 3 characters in string 3 3 3
3 3 3 3 3 3
3 3 3 3 3 3
3 general 3 General 3 Max number of 3 3 3
3 3 String 3 characters in string 3 3 3
3 3 3 3 3 3
3 3 3 3 3 3
3 octet 3 OCTET STRING3 Max numbers of octets 3 3 3
3 3 3 in string 3 3 3
3 3 3 3 3 3
3 private- 3 Floating 3 3 The minimum 3 Number of bits 3
3 class-number 3 Point 3 3 number of bits 3 required to 3
3 3 Number 3 3 required to be 3 represent the 3
3 3 3 3 maintained in 3 largest unbiased3
3 3 3 3 the mantissa for3 integer exponent3
3 3 3 3 relative 3 in 2's 3
3 3 3 3 precision 3 complement 3
3 3 3 3 3 3
3 3 3 3 3 3
3 3 3 3 3 3
3 3 3 3 3 3
3 univer- 3 UTCTime 3 <not applicable> 3 3 3
3 time 3 3 3 3 3
3 3 3 3 3 3
3 gen-time 3 Generalized 3 <not applicable> 3 3 3
3 3 Time 3 3 3 3
3 3 3 3 3 3
3 boolean 3 BOOLEAN 3 <not applicable> 3 3 3
3 3 3 3 3 3
3 null 3 NULL 3 <not applicable> 3 3 3
3 3 3 3 3 3
@DDDDDDDDDDDDDDADDDDDDDDDDDDDADDDDDDDDDDDDDDDDDDDDDDDADDDDDDDDDDDDDDDDDADDDDDDDDDDDDDDDDDY
Note: The string length parameter specifies the actual number of
characters from the referenced character set. It does not include any
escape sequences or overhead from the encoding.
The primitive data types and minimal size ranges that an
implementation must accept for storage are given in Table 6.3.
Table 6.3 FTAM primitive data types
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3Primitive Data Type Minimum Range (Octets)3
3 3
3ASN.1 INTEGER 1 - 2 3
3ASN.1 BIT STRING 0 - 1 3
3ASN.1 IA5String 0 - 134 3
3ASN.1 GeneralString 0 - 134 3
3ASN.1 GraphicString 0 - 134 3
3ASN.1 OCTET STRING 0 - 512 3
3ASN.1 BOOLEAN 3
3ASN.1 NULL 3
3ASN.1 GeneralizedTime 3
3ASN.1 UniversalTime 3
3NBS-AS1 FloatingPointNumber mantissa 1-23 bits 3
3 exponent 0-8 bits 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
Notes:
1. The primitive data types and their maximum ranges for a specific
file as described by the parameters above are maintained in the
<contents type> file attribute. The <contents type> file
attribute value is established at the file's creation and cannot
be changed via FTAM for the life of the file. This implies that
the data element types and ranges and data unit formats are fixed
for all accessors of that file as long as the file exists.
2. The syntax for floating point numbers is part of the definition
of NBS abstract syntax AS1 in Annex 6A Part 3. It is derived
from existing standards IEC 559 and IEEE 754.
6.10.1 Character Sets
Implementation of a character set in FTAM is understood as:
o a transfer syntax is defined for the character set
o document types are defined using the character set in
their abstract syntactic definition
o documents of those types are stored in the Virtual File
Store as defined in the character set specification.
They are written into the VFS and read from the VFS as
defined by the abstract syntax and the transfer syntax
for the document type. It is not in the scope of FTAM
Agreements to specify the local representation of those
documents in the Real Filestore, nor to specify
rendition of graphic characters or control characters
on character imaging devices. These renditions are
possible agreements between applications using FTAM for
their communication.
The character sets IA5 and ISO 8859-1 shall always be
implemented.
6.10.1.1 IA5 Character Set
The International Reference Version (IRV) of IA5 is
available for use when there is no requirement to use a
national or an application-oriented version. In information
interchange, the IRV is assumed unless a particular
agreement exists between sender and receiver of the data.
The graphic characters allocated to the IRV are as specified
in Table 6.4.
Table 6.4. IRV Graphic Character Allocations
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 Graphic Name Coded Representation 3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3 3
3 # Number sign 2/3 3
3 3
3 o Currency sign 2/4 3
3 3
3 @ Commercial at 4/0 3
3 3
3 [ Left square bracket 5/11 3
3 3
3 \ Reverse solidus 5/12 3
3 3
3 ] Right square bracket 5/13 3
3 3
3 ^ Circumflex accent 5/14 3
3 3
3 ' Grave accent 6/0 3
3 3
3 { Left curly bracket 7/11 3
3 3
3 3 Vertical line 7/12 3
3 3
3 } Right curly bracket 7/13 3
3 3
3 ~ Tilde, overline 7/14 3
3 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
It should be noted that no substitution is allowed when using the IRV
and that the facility of combined vertical and horizontal movements of
the active position does not apply to any format effectors.
It is permitted to use composite graphic characters and there is no
limit to their number. Because of this freedom, their processing and
imaging may cause difficulties at the receiving end. Therefore
agreement between sender and receiver of the data is recommended if
composite characters are used.
Note: Attention is drawn to the fact that different national
character sets exist.
(See ISO 646 or CCITT Recommendation T.50 for more information)
6.10.1.2 8859-1 Character Set
The Latin Alphabet No.1 (ISO 8859-1) is used to specify the
printable characters of G0 and G1. C0 control characters
and their associated rules are taken from the IA5
definition.
6.10.2 Document Type Negotiation Rules
6.10.2.1 Connection Establishment
In connection establishment the <contents type list>
parameter is used only to establish presentation contexts.
Both the <document type name> form and the <abstract syntax
name> form are supported.
6.10.2.2 File Creation
An <F-CREATE request> FPDU must contain a <document type
name> value in its <initial attributes> parameter.
If the specified document type requires parameterization,
then these parameters must be supplied, otherwise the <F-
CREATE request> may be rejected.
Notes:
1. It is understood that <permitted actions> sub-
field of <initial attributes> parameter will
always be used at <F-CREATE request>. The value
may be changed by the Responder.
2. If the <document type name> used requires DU
syntax parameters and one of the parameters
specifies 'FloatingPointNumber' as a primitive
data type, the request may be rejected, in case
the optional type 'FloatingPointNumber' is not
supported by the Responder.
6.10.2.3 File Opening
The <document type name> form (with appropriate parameters
as specified in 8871-2, clause 12.3) shall always be used
when proposing a <contents type>; as an alternative the
'ContentsTypeUnknown' value may be used in the <F-OPEN
request>. An <F-OPEN response> shall use the <document type
name> option (with appropriate parameters) in the <contents
type> field.
This allows the receiving entity to use the <document type
name> attributed to the file instead of receiving a
<constraint set name> and <abstract syntax name> pair, which
does not reflect the file information contained in the FTAM
and NBS document types.
This document type name is either a value from the set of
base document type names as negotiated upon connection
establishment or a document type name, for which an
appropriate presentation context was established.
Notes:
1. An <F-OPEN response> without a <document type name>
(but carrying the <constraint set name> and <abstract
syntax name> form) may cause the Initiator to issue an
<F-CLOSE request>.
2. If the <document type name> used requires DU syntax
parameters and one of the parameters specifies
'FloatingPointNumber' as a primitive data type, the
request may be rejected, in case the optional type
'FloatingPointNumber' is not supported by the
Responder.
6.10.3 Relationship Between DUs, DEs and Document Types
"Abstract Syntax" is used to refer to the syntactic information
which is architecturally passed between the Application and
Presentation Layers. The Abstract Syntax defines Data Element
(DE) types which are not necessarily ASN.1 primitive types. A
Data Element (DE) is the smallest piece of data whose identity is
necessarily preserved by the Presentation Service. Data types
may be made up of other data types. Data Elements are not
defined in terms of other Data Elements.
A Data Unit (DU) is a sequence of one or more Data Elements.
Architecturally, entire, single DEs are passed into and out of
the application process. In a real implementation, DUs may be
passed.
To maintain DU boundaries during transfer, file structuring
information must be passed (ISO8571-FADU definition in ISO 8571-
2, clause 7.5). A Data Element is referred to as a File-
Contents- Data-Element in the ISO8571-FADU definition.
Document types refer to aspects of local processing and storage.
They describe:
o structural relationship between DUs,
o structure of DUs, called DU syntax, and
o DE types found in the file.
Because document types pertain to local processing and storage,
the DU syntax makes assertions about the syntax and the size of
DUs (records) in storage. Parameters on the document types
provide this information about the syntax and size of the DUs.
6.11 F-CANCEL ACTION
When an F-CANCEL is sent or received, the following occurs:
o no more data is sent,
o checkpoint numbers are removed, and
o state of the file is implementation dependent.
Note: When mapping F-CANCEL on P-RESYNCHRONIZE (abandon) it is
required that P-SYNC-MINOR be used after F-READ/F-WRITE (see
ISO 8571-4 clauses 13, 14).
6.12 IMPLEMENTATION INFORMATION AGREEMENTS
o The <implementation information> parameter of <F-INITIALIZE>
FPDU is not required by these Agreements.
o It may be used to pass user version information as a series of
values, separated by ';'.
o The following will indicate conformance to the NBS Phase 2
Agreements: NBS-Phase2.
Note: The list of possible values may be enlarged for future
FTAM phases or FTAM profiles of other bodies.
o This parameter is for information only; it is not used for
negotiation.
The establishment of an FTAM regime should not be rejected only
because of an unknown <implementation information> value.
6.13 DIAGNOSTIC AGREEMENTS
o The <diagnostic> parameter is supported; a value in the
<response> PDU is needed when the <action result> or <state
result> is not zero. (The nature of these agreements is to
provide <diagnostic> information when any result parameter is not
'success'.)
o General catch-all diagnostic action is discouraged.
o The <further details> subfield is supported. It will be encoded
as GraphicString, but is restricted to IA5 (IRV, graphic
characters) and ISO 8859-1 only.
o Use of F-P-ABORT for other than protocol errors and catastrophic
situations is discouraged.
o When returning an error status in a file management related
diagnostic (i.e., <F-READ-ATTRIBUTE response> or <F-
CHANGE-ATTRIBUTE response>), identify the erroneous attribute by
using the first two characters of <further details> to hold a
2-digit number (encoded as IA5String) from the <F-READ-ATTRIBUTE
request> attributes abstract syntax definition (ISO 8571-4,
clause 20.3).
00 Filename
01 Permitted Actions
02 Contents Type
03 Storage Account
04 Date and Time of Creation
05 Date and Time of Last Modification
06 Date and Time of Last Read Access
07 Date and Time of Last Attribute Modification
08 Identity of Creator
09 Identity of Last Modifier
10 Identity of Last Reader
11 Identity of Last Attribute Modifier
12 File Availability
13 File Size
14 Future Filesize
15 Access Control
16 Legal Qualifications
17 Private Use
The set of file management diagnostics, found in ISO 8571-3 Annex
A, must be supported.
o In the case where a specific parameter can in no way be
accommodated then the request fails and a <diagnostic> indicating
one such parameter should be returned by the responder. In the
case where a negotiable parameter cannot be accommodated with
exactly the value requested but is negotiated to a different
value (as defined in the standard) then the request formally
succeeds but informative <diagnostics> indicating those
parameters negotiated should be returned.
o In order to provide for robust applications using FTAM, well
defined and precise diagnostics are required to be returned by
responding implementations whenever an action cannot be carried
out precisely as requested with respect to non-negotiable
parameters. All such applicable diagnostics will be returned in
those cases. An action is carried out precisely as requested
with respect to a parameter when the value of that parameter on
the <request> FPDU is equal to the value in effect during or
subsequent to the action, depending on whether the action is
regime control.
Diagnostics exist to signal 'parameter not supported' and
Responder implementations shall issue all appropriate
diagnostics. The <further details> subfield of the <diagnostic>
parameter shall specify the parameter which is not implemented.
6.14 CONCURRENCY
The <concurrency control> used by default on actions requested by an
<F-SELECT indication> or <F-CREATE indication> service are:
'shared' for read and read attribute
'exclusive' for all other actions
The default for actions not requested is specified as 'not required'
as per ISO 8571-3.
Note: A local implementation may choose to be more restrictive in
order to assure file consistency for concurrent accessors.
FADU locking is not required.
6.15 REQUESTED ACCESS
The <requested access> parameter on <F-SELECT> or <F-CREATE> is used
to specify the actions which the Initiator may perform during the file
selection. The value of the <requested access> parameter is compared
by the Responder to the <access control> and <permitted actions> file
attributes and concurrency controls (including those requested by the
Initiator) currently in place on the file. If the value of the
<requested access> parameter is not consistent with either <access
control>, <permitted actions>, or concurrency controls in place, then
the <F-SELECT> or <F-CREATE> must be rejected.
<requested access> is consistent with <access control> if, for each
action requested, that action either requires no password, or the
required password has been specified on the <F-SELECT request> or <F-
CREATE request>.
<requested access> is consistent with <permitted actions> if, for each
action requested, that action is allowed by the <permitted actions>
file attribute.
<requested access> is consistent with <concurrency control> requested
on the <F-SELECT> or <F-CREATE> if, for each action requested, that
action has not been specified as 'not required' or 'no access' in the
<concurrency control> parameter.
<requested access> is consistent with concurrency controls in place on
the file if for each action requested no other accessor of the file
has set the concurrency control for that action to either 'exclusive'
or 'no access'.
6.16 SECURITY
6.16.1 Initiator Identity and Filestore Password
The <initiator identity> and <filestore password> parameters for
an implementation acting as an Initiator are supported. These
parameters are optional for an implementation acting as a
Responder.
The syntax of <initiator identity> and <filestore password> is
system-dependent. <initiator identity> and <filestore password>
will represent account information on the local system, which
may be different from the <account> parameter.
6.16.2 Access Passwords
The <access passwords> and <create password> parameters for an
implementation acting as an Initiator are supported if the
Security Group of attributes is supported. These parameters for
an implementation acting as a Responder are optionally supported
if the Security Group is supported.
6.16.3 Implementation Responsibilities
It is the responsibility of each local system to provide security
for its own real filestore. Encryption of passwords will not be
done by FTAM.
A user of the file service must be known by the Responder.
"Known" is defined by the local Filestore, and is dependent on
the level of security provided by the local Filestore.
6.17 REQUIREMENT FOR CONFORMANT IMPLEMENTATIONS
This section gives the criteria to be satisfied by every
implementation of FTAM that conforms to these Agreements.
Conformance to these Agreements is stated in terms of the different
roles occupied by FTAM implementations. The interoperability of
certain configurations of these roles motivates this approach.
Interoperable configurations of these roles are given in section
6.17.1.
The only function provided by every conformant implementation is the
transfer of unstructured binary files in their entirety. It must be
recognized that such simple transfer, while commonly understood and
generally important, will not support all applications of FTAM.
Section 6.18 defines Implementation Profiles of FTAM services and
protocol that can provide other specific functions. Those other
functions exploit the access and management capabilities of FTAM. The
unconstrained service class (with appropriately chosen functional
units) can be used to provide the functions of any of the
Implementation Profiles. Users of FTAM must consider carefully what
functions they require. They must examine all the Implementation
Profiles and select according to their needs.
Implementation conforming to these Agreements require adherence to the
General Agreements in sections 6.5 through 6.16 of these Agreements.
6.17.1 Interoperable Configurations
Any implementation conforming to this specification must be able
to act in at least one of the following role combinations:
1. initiator and receiver,
2. initiator and sender,
3. responder and sender,
4. responder and receiver.
Minimal implementations of combination 1 will interoperate with
minimal implementations of combination 3. Minimal
implementations of combination 2 will interoperate with minimal
implementations of combination 4.
Any implementations of roles l and 3 will be able to interoperate
at the intersection of their capabilities (which will be at least
the minimal capabilities described in sections 6.17.3 to 6.17.8).
Any implementations of roles 2 and 4 will be able to interoperate
at the intersection of their capabilities (which will be at least
the minimal capabilities described in sections 6.17.3 to 6.17.8).
These role combinations and this interoperability are shown in
Table 6.5 below.
Table 6.5 Interoperable configurations
ZDDDDDDDDDDDDDDDDDDDDDDDRDDDDDDDDDDDDDDDDDDDDDDBDDDDDDDDDDDDDDDDDDDDDDD?
3 : Initiator 3 Responder 3
3 GDDDDDDDDDBDDDDDDDDDDDDEDDDDDDDDDBDDDDDDDDDDDDD4
3 : sender 3 receiver 3 sender 3 receiver 3
3MMMMMMMMMMMQMMMMMMMMMMMNMMMMMMMMMXMMMMMMMMMMMMXMMMMMMMMMXMMMMMMMMMMMMM3
3 3 sender : 3 3 3 x 3
3 Initiator CDDDDDDDDDDDWDDDDDDDDDEDDDDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDD3
3 3 receiver : 3 3 x 3 3
CDDDDDDDDDDDEDDDDDDDDDDDWDDDDDDDDDEDDDDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDD4
3 3 sender : 3 x 3 3 3
3 Responder CDDDDDDDDDDDWDDDDDDDDDEDDDDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDD4
3 3 receiver : x 3 3 3 3
3 3 : 3 3 3 3
@DDDDDDDDDDDADDDDDDDDDDDPDDDDDDDDDADDDDDDDDDDDDADDDDDDDDDADDDDDDDDDDDDDY
6.17.2 Relationship to ISO 8571--The FTAM Standard
Any implementation in conformance to ISO 8571 (as defined in ISO
8571-4, clause 22 (Conformance)), in addition to the
implementation of the minimal protocols and roles enumerated in
sections 6.17.3 to 6.17.8, is considered to be in conformance
with these Agreements. Any implementation violating any of the
conformance statements in ISO 8571-4 is considered to be in
violation of these Agreements.
6.17.3 Requirements for Document Type Support
The document type FTAM-3 shall be supported for purposes of
transfer and storage. The details regarding support for FTAM-3
in the FTAM dialogue are given in section 6.10.
Support of document types other than FTAM-3 is not required for
conformant implementations. Support for document types described
in these Agreements also entails support for:
o the semantics given in their description and further
qualified in 6.10
o the preferred transfer syntax "Basic Encoding of a
single ASN.1 type"
6.17.4 Initiators
Every implementation of an FTAM Initiator shall support:
o the kernel protocol and its mandatory parameters with
minimum ranges [Minimum required ranges are specified
in section 6.17.8.],
o the grouping protocol and the <threshold> parameter
with a value of at least 2 for use in the file transfer
class,
o at least one of the read or write protocols [Specific
conformance for reading and writing is defined in
sections 6.17.6 and 6.17.7.],
and support the applicable procedures defined in ISO 8571-4
clauses 8.1 (FTAM regime establishment), 8.2 (FTAM regime
termination), 8.3 (File selection), 8.4 (File deselection), 8.9
(File open), 8.10 (File close), 8.11 (Begin group), 8.12 (End
group), and 10 (File general actions). To support the above
protocols and procedures the implementation shall always support
the kernel functional unit and additionally shall be able to:
o request the grouping and at least one of the read or
write functional units,
o request the file transfer class with the <service
class> parameter,
o request the document type FTAM-3 using the <document
type name> form of the <contents type> parameter,
o request the <FTAM quality of service> parameter with
value 0 and accept in all cases the returned value 0,
and
o request a <communication quality of service> consistent
with the transport definition in these Agreements
as part of the Filestore initialization procedures in ISO 8571-4
clause 8.1, FTAM regime establishment.
Initiators must be able to operate under all circumstances if the
above minimum values are successfully negotiated and returned on
an <F-INITIALIZE response> PDU. Initiators must be able to
operate with any downward negotiation of requested parameter
values as described in the standard.
Should the supporting services break down, such that FTAM
communication is impossible, the FTAM protocol machine shall
notify the user with an <F-P-ABORT indication> and <diagnostic>
value with identifier 1011, as well as any known <further
details>.
Note: Interworking may not be possible between Initiators not
supporting attributes of the Storage Group and Security Group,
and Responders requiring these attributes to be used.
6.17.5 Responders
Every implementation of an FTAM Responder shall support:
o the kernel protocol and its mandatory parameters with
minimum ranges [Minimum required ranges are specified
in section 6.17.8.],
o the grouping protocol and the <threshold> parameter
with a value of at least 2 for use in the file transfer
class,
o at least one of the read or write protocols [Specific
conformance for reading and writing is defined in
sections 6.17.6 and 6.17.7],
and support the applicable procedures, defined in ISO 8571-4
clauses 9.1 (FTAM regime establishment), 9.2 (FTAM regime
termination), 9.3 (File selection), 9.4 (File deselection), 9.9
(File open), 9.10 (File close), 9.11 (Begin group), 9.12 (End
group), and 10 (File general actions). To support the above
protocols and procedures the implementation shall always support
the kernel functional unit and additionally shall be able to:
o accept requests for the grouping and at least one of
the read or write functional units,
o accept requests for the file transfer class with the
<service class> parameter,
o accept the document type FTAM-3 using the <document
type name> form of the <contents type> parameter,
o accept requests for an <FTAM quality of service>
parameter with any value but may respond with the value
0, and
o accept requests for a <communication quality of
service> consistent with the transport definition in
these agreements
as part of the filestore initialization procedures in ISO 8571-4
clause 9.1, FTAM regime establishment.
Responders must be able to operate under all circumstances if the
above minimum values are requested on an <F-INITIALIZE request>
PDU. Responders must not negotiate upward in the sense described
in the standard.
Responders must complete each action requested and supported in a
manner consistent with its description in ISO 8571-2 clauses 10
(Actions on complete files) and 11 (Actions for file access), and
must interpret each supported attribute in a manner consistent
with its definition in ISO 8571-2 clause 12 (File attributes).
Under circumstances where actions cannot be carried out either as
requested or consistently with ISO 8571-2 clause 10 (Actions on
complete files) and 12 (Actions for file access), the Responder
must return at least one diagnostic indicating:
o if the failure was due to either a protocol or
Filestore failure, and then:
-- precisely which action failed,
-- at least one of the parameters that could not be
accommodated with the diagnostic type indicating
at least the degree of failure, as given by the
action and state result parameter, or
o that the failure was due to unforeseen system shutdown.
Should the supporting services break down, such that FTAM
communication is impossible, the FTAM protocol machine shall
notify the user with an <F-P-ABORT indication> and <diagnostic>
with identifier 1011, as well as inform the user of any known
<further details>.
6.17.6 Senders
Every implementation of an FTAM sender shall support the read
functional unit as Responder or the write functional unit as
Initiator, and support the applicable procedures defined in ISO
8571-4 clauses 11 (State of the bulk data transfer activity), 12
(Bulk data transfer protocol data units), 15 (Bulk data transfer
sending entity actions), 17.1 (Discarding), and 17.2 (Cancel).
To support those procedures the implementation shall be able to
send files of the document type FTAM-3 and shall be able to send
them as user data in PPDUs in blocks of up to 7168 octets.
6.17.6.1 Initiator Senders
Every implementation of an FTAM sender which is also an FTAM
Initiator shall support:
o the write functional unit and protocol, and
o for the document type FTAM-3 the following bulk
data transfer specification parameters:
FADU operation replace
FADU identity first
and support the applicable procedures, defined in ISO 8571-4
clause 13 (Bulk data transfer initiating entity actions).
6.17.6.2 Responder Senders
Every implementation of an FTAM sender which is also an FTAM
Responder shall support:
o the read functional unit and protocol, and
o for the document type FTAM-3 the following bulk
data transfer specification parameters:
FADU identity first
Access context UA
and support the applicable procedures, defined in ISO 8571-4
clause 14 (Bulk data transfer responding entity actions).
6.17.7 Receivers
Every implementation of an FTAM receiver shall support the read
functional unit as Initiator or the write functional unit as
Responder, and support the applicable procedures, defined in ISO
8571-4 clauses 11 (State of the bulk data transfer activity), 12
(Bulk data transfer protocol data units), 16 (Bulk data transfer
receiving entity actions), 17.1 (Discarding), and 17.2 (Cancel).
To support those procedures the implementation shall be able to
receive files of the document type FTAM-3 and shall be able to
receive them as user data in PPDUs in blocks of at least 7168
octets.
6.17.7.1 Initiator Receivers
Every implementation of an FTAM receiver which is also an
FTAM Initiator shall support:
o the read functional unit and protocol, and
o for the document type FTAM-3 the following bulk
data transfer specification parameters:
FADU identity first
Access context UA
and support the applicable procedures, defined in ISO 8571-4
clause 13 (Bulk data transfer initiating entity actions).
6.17.7.2 Responder Receivers
Every implementation of an FTAM receiver which is also an
FTAM Responder shall support:
o the write functional unit and protocol, and
o for the document type FTAM-3 the following bulk
data transfer specification parameters:
FADU operation replace
FADU identity first
and support the applicable procedures, defined in ISO 8571-4
clause 14 (Bulk data transfer responding entity actions).
6.17.8 Minimum Ranges
Any implementation of any conformant FTAM configuration shall be
able to receive and meaningfully process all mandatory parameters
for all functional units supported as well as the <diagnostic>
parameter within at least the minimum ranges of values given in
Table 6.6. A conforming implementation may support a wider range
of values for any parameter.
Table 6.6 Required minimal parameter support
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 Parameter Minimum Range 3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3general diagnostic Values as specified in ISO 8571-3 Annex A 3
3 (Diagnostic parameter values) Tables 44, 3
3 45 and 46 which correspond directly to 3
3 mandatory parameters. 3
3 action result All values. 3
3 state result All values. 3
3 3
3F_INITIALIZE 3
3 3
3 functional units1 'read' (for initiator/receivers and 3
3 responder/senders) and 'grouping' 3
3 or 3
3 'write' (for initiator/senders and 3
3 responder/receivers) and 'grouping' 3
3presentation context management2 'Not required.' 3
3 all others As specified in sections 6.17.4 and 3
3 6.17.5 above. 3
3 3
3 3
3F_SELECT 3
3 attributes Only <filename> is used with a minimum 3
3 supportable length of 8 characters. Any 3
3 other attribute supported for other 3
3 services must have minimum supported 3
3 lengths as in ISO 8571-2 clause 15 3
3 (Minimum attribute ranges) Table 2. 3
3 3
3 requested access 'read' for initiator/receivers 3
3 'read' for responder/senders 3
3 'replace' for initiator/senders 3
3 'replace' for responder/receivers 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
(Continued on next page.)
Table 6.6 Required minimal parameter support, continued
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 Parameter Minimum Range 3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3F_OPEN 3
3 processing mode 'read' for initiator/receivers 3
3 'read' for responder/senders 3
3 'replace' for initiator/senders 3
3 'replace' for responder/receivers 3
3 3
3 contents type 'FTAM-3' 3
3 3
3F_READ 3
3 FADU identity 'first' 3
3 access context 'UA' 3
3F_WRITE 3
3 FADU operation 'read' for initiator/receivers 3
3 'read' for responder/senders 3
3 'replace' for initiator/senders 3
3 'replace' for responder/receivers 3
3 3
3 FADU identity 'first' 3
3 3
3F_BEGIN_GROUP 3
3 3
3 threshold3 For file transfer (a minimal required 3
3 function) 2. 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
For any other supported parameters, minimum ranges are taken from
the minimum ranges for the attribute corresponding to each as in
ISO 8571-2 Table 4.
DDDDDDDDDDDDDDD
Notes:
1. The parameters, functional units, and presentation context
management are not ordered, so "minimum value" cannot be
formally defined. The above values are those required for
conformance to these Agreements but no value conformant to
ISO 8571 for use in other applications is regarded to be in
violation of these Agreements.
2. Other functional units (and service classes) for defined
implementations may also be valid provided that they are
implemented in accordance with these Agreements,
specifically section 6.17.8.
3. Every implementation must support the <threshold> value 2 to
provide the basic required function of file transfer; any
other value in other applications is acceptable.
6.17.9 Use of Lower Layer Services
o Support for the Presentation Context Management
functional unit is not required.
o Implementations will support the Session, Presentation,
and ACSE requirements as stated in section 5.
Note: Implementation of the Session Resynchronize and the Minor
Synchronize functional units is highly recommended, since the F-
CANCEL service may be less effective when mapped to S-DATA.
6.18 IMPLEMENTATION PROFILES
This section defines Implementation Profiles for the specific
functions of:
o File Transfer
o File Access
o File Management.
Those definitions are expressed in terms of:
o Document Types
o Attributes
o Service Classes (both service elements and their
parameters).
This by no means defines all possible Implementation Profiles.
The following Implementation Profiles are defined:
T1: Simple File Transfer
T2: Positional File Transfer
T3: Full File Transfer
A1: Simple File Access
A2: Full File Access
M1: Management.
Implementation Agreements have been reached for the following service
classes. Note that any given implementation may support more than one
service class.
o File Transfer
o File Access
o File Management
o Unconstrained
o File Transfer and Management
Support of an Implementation Profile requires adherence to:
1. corresponding definition in 8571-3 clause 8 and any related
procedures in 8571-4 clause 8-17,
2. requirements given in sections 6.5-6.18 of these Agreements, and
3. requirements for parameter and attribute support as defined in
section 6.17.8.
6.18.1 General Requirements for the Defined Implementation
Profiles
o Implementations will be able to act either as Initiator or
Responder or both.
o Implementations must support diagnostics as described in
section 6.13 of these Agreements.
o Implementations that support the file access service class
will support access to sequential files. Support of
sequential files entails hierarchy of depth and arc length
equal to 1. Other hierarchy depth and arc lengths are not
precluded by these agreements.
6.18.2 Intentionally Left Empty
6.18.3 Document Type Requirements for the Defined
Implementation Profiles
Implementations conformant to Implementation Profiles defined in
Table 6.7 will support the following document types with the
caveats and procedures given. Those document types are defined
in Appendix 6A and section 6.10 of these Agreements, and in ISO
8571-2.
o FTAM-1
o FTAM-2
o FTAM-3
o NBS-6
o NBS-7
Note: Support of this document type entails the
naming of FADUs by their position in
preorder traversal.
Caveat: Other methods of naming FADUs depend on the
system, application, and specific file, and
as such are not described here.
o NBS-8
o NBS-9
Support for any document type requires the ability to transfer
and store the abstract syntax given in its definition. These
Agreements do not specify techniques or formats for storage.
Caveat: Specific abstract syntaxes for the parameterized
document types NBS-6,7,8 are not specified in these
Agreements.
Any document type supported must be identifiable by its document
type name as given in ISO 8571-2 and in Appendix 6A of these
Agreements and, where defined, the parameterization scheme given
in section 6.10 of these Agreements.
For conformance to NBS-9 a Responder is only required to return
the <filename> attribute, subject to local security and access
control. All other requested attributes need not be returned.
Systems supporting the NBS-9 document type shall make available
an NBS-9 document called 'DIRLIS'. This document can be used to
obtain a listing of files and their associated attributes from a
remote Filestore.
File security issues related to NBS-9 are subject to the security
agreements outlined in section 6.16.
6.18.4 Parameters for the Defined Implementation Profiles
o
o
o Implementations will support the <contents type list>
parameter on the <F-INITIALIZE> service element. The
initiating service must supply a value for this
parameter.
o Implementations will support the <diagnostic> parameter
as stated in section 6.13 of these Agreements.
o The <initiator identity> parameter is supported. Use
must be consistent with section 6.16 of these
Agreements.
o Implementations are not precluded from using other
parameters for security and/or accounting. Responders
must state the semantics applying to <account> and
<charging> parameters. The Responder's minimum
implementation is to accept but ignore the <account>.
and to return a <charging> value of zero.
6.18.5 Parameter Ranges for the Defined Implementation
Profiles
Parameter ranges for Implementations Profiles are as stated for
primitive data types in section 6.10 of these agreements.
6.18.6 File Attribute Support for Implementations
Implementations of the Implementation Profiles will support file
attributes or attribute groups in the following ways.
o mandatory
This feature is mandatory in the ISO 8571-2
standard and shall therefore be implemented by all
implementations claiming conformance to these
Agreements.
o supported
This feature shall be implemented by all
implementations claiming conformance to these
Agreements (for attributes, this implies that at
least the minimum range of attribute values, as
defined in ISO 8571-2 clause 15, shall be
supported). Conformant implementations shall also
be able to interwork with other implementations
that do not support this feature by negotiating
out the corresponding features.
o optionally supported
Implementations claiming conformance to these
Agreements may or may not implement this feature
(for attributes, this implies that at least either
the minimum range of attribute values, as defined
in ISO 8571-2 clause 15, shall be supported or
that the 'no value available' result shall be
supplied). If an attribute group with a support
level of 'optionally supported' is chosen to be
supported, then all the attributes of this group
that are classified as 'mandatory' or 'supported'
shall be supported.
o not supported
This feature is outside the scope of these
Agreements.
Kernel Group mandatory
o Filename mandatory
o Permitted Actions mandatory
o Contents Type mandatory
Storage Group optionally supported
o Storage Account optionally supported
o Date and Time of Creation optionally supported
o Date and Time of Last Modification optionally supported
o Date and Time of Last Read Access optionally supported
o Date and Time of Last Attribute Modification optionally supported
o Identity of Creator optionally supported
o Identity of Last Modifier optionally supported
o Identity of Last Reader optionally supported
o Identity of Last Attribute Modifier optionally supported
o File Availability supported
o Filesize supported
o Future Filesize optionally supported
Security Group optionally supported
o Access Control supported
o Legal Qualifications optionally supported
Private Group not supported
Table 6.7 Implementation profile support requirements
ZDDDDDDDDDDDDDDDDDDDDDDDDDDBDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 3 Service Class 3
3 Functional Unit 3 T M A T&M UNCST 3
CDDDDDDDDDDDDDDDDDDDDDDDDDDEDDDDDDDDDBDDDDDDDDDBDDDDDDDDDBDDDDDDDDDBDDDDDDDDD4
3 3 3 3 3 3 3
3 Kernel 3 T1,T2,T33 M1 3 A1,A2 3 3 3
3 Read (See note 3.) 3 T1,T2,T33 3 A1,A2 3 3 3
3 3 3 3 3 3 3
3 Write (See note 3.) 3 T1,T2,T33 3 A1,A2 3 3 3
3 3 3 3 3 3 3
3 Limited File Mgmnt. 3SeeNote 63 M1 3SeeNote 63 See 3 See 3
3 Enhanced File Mgmnt. 3 3 M1 3 3 3 3
3 Grouping 3 T1,T2,T33 M1 3 3 3 3
3 File Access 3 3 3 A1,A2 3 3 3
3 3 3 3 3 3 3
3 Document Types 3 3 3 3 3 3
3 3 3 3 3 3 3
3 FTAM-1 3 T1,T2,T33 [M1] 3 A1,A2 3 3 3
3 FTAM-2 3 T2,T3 3 [M1] 3 A1,A2 3 3 3
3 FTAM-3 3 T1,T2,T33 [M1] 3 A1,A2 3 Note 3 Note 3
3 3 3 3 3 3 3
3 NBS-6 3 [T2],T3 3 [M1] 3 [A1],A23 4 3 5 3
3 3 3 3 3 3 3
3 NBS-7 3 [T2],T3 3 [M1] 3 [A1],A23 3 3
3 3 3 3 3 3 3
3 NBS-8 3 T3 3 [M1] 3 A2 3 3 3
3 3 3 3 3 3 3
3 NBS-9 3[T1],[T2]3 [M1] 3 3 3 3
3 3[T3] 3 3 3 3 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDADDDDDDDDDADDDDDDDDDADDDDDDDDDADDDDDDDDDADDDDDDDDDY
Notes: to 6.18.3 and Table 6.7
1. The Management Implementation Profile is only to be implemented in
conjunction with one of the Transfer or Access Profiles.
2. Profile T2 is subset of T3. A1 and T1 are subsets of A2 and T2,
respectively.
3. Profiles T1, T2, and T3 require the support of read and/or write
functional units.
4. Support of the <File Transfer and Management> service class is
optional. If an implementation is capable of supporting
Implementation Profile M1 and one of the T-Implementation Profiles,
the Initiator may choose to request the <File Transfer and Management>
service class. Any implementation so doing must be prepared for the
possibility of rejection of the request by the Responder.
Support of the <File Transfer and Management> service class is
optional. The rules for including it in a request and for the
response to it are as given in ISO 8571-3, clause 10.1. Any
implementation including TM in the request must be prepared for the
possibility that it might be removed from the response.
5. The support of the <Unconstrained> service class is optional. There
are no constraints on this service class beyond those of ISO 8571.
6. Limited File Management is not required for the T- and A-
Implementation Profiles, but very often it will be a user request to
have limited file management functionality available together with
file transfer and file access functions. So Limited File Management
may be added as an option to the T- and A- Implementation Profiles.
7. [] in Table 6.7 specifies that the document type is optional for the
respective Implementation Profile. For M1 the support level depends
on the T- or A- Implementation Profile, in conjunction with which M1
is implemented.
6.19 PROVISION OF SPECIFIC FUNCTION
6.19.1 Implementation Profile T1: Simple File Transfer
Implementation Profile T1 provides the function of transferring
entire files at the external file service level for files with an
unstructured constraint set. This includes support of the
document types:
o FTAM-1 "ISO FTAM unstructured text"
o FTAM-3 "ISO FTAM unstructured binary"
o NBS-9 "NBS-9 file directory file" (optional)
This Implementation Profile supports file transfer and not file
access, that is, the ability to:
o read a complete file
and/or
o write (replace, extend) to a file.
6.19.2 Implementation Profile T2: Positional File Transfer
Implementation Profile T2 provides the function of transferring
files at the external file service level for files with an
unstructured or flat constraint set. This includes support of
the document types:
o FTAM-1 "ISO FTAM unstructured text"
o FTAM-2 "ISO FTAM sequential text"
o FTAM-3 "ISO FTAM unstructured binary"
o NBS-6 "NBS-6 FTAM sequential file" (optional)
o NBS-7 "NBS-7 FTAM random access file" (optional)
o NBS-9 "NBS-9 file directory file" (optional)
This Implementation Profile supports file transfer and not file
access, that is, the ability to:
o read a complete file or a single FADU which is
identified by position
and/or
o write (replace, extend, insert depending on constraint
set and document type) to a file or an FADU.
This Implementation Profile is upwardly compatible to T1 for the
transfer of unstructured files.
6.19.3 Implementation Profile T3: Full File Transfer
Implementation Profile T3 provides the function of transferring
files at the external file service level for files with an
unstructured, flat or general hierarchical constraint set. This
includes support of the document types:
o FTAM-1 "ISO FTAM unstructured text"
o FTAM-2 "ISO FTAM sequential text"
o FTAM-3 "ISO FTAM unstructured binary"
o NBS-6 "NBS-6 FTAM sequential file"
o NBS-7 "NBS-7 FTAM random access file"
o NBS-8 "NBS-8 FTAM indexed file"
o NBS-9 "NBS-9 file directory file" (optional)
This Implementation Profile supports file transfer and not file
access, that is, the ability to:
o read a complete file or a single FADU which is
identified by key or by position
and/or
o write (replace, extend, insert depending on constraint
set and document type) to a file or an FADU.
This Implementation Profile is upwardly compatible to T1 for the
transfer of unstructured files.
6.19.4 Implementation Profile A1: Simple File Access
Implementation Profile A1 provides the function of transfer of
and access to files with unstructured or flat constraint sets at
the external file service level. This includes support of the
document types:
o FTAM-1 "ISO FTAM unstructured text"
o FTAM-2 "ISO FTAM sequential text"
o FTAM-3 "ISO FTAM unstructured binary"
o NBS-6 "NBS-6 FTAM sequential file" (optional)
o NBS-7 "NBS-7 FTAM random access file" (optional)
This Implementation Profile supports file transfer and file
access, that is the ability to:
o read a complete file or FADUs which are identified by
position,
o write (replace, extend, insert depending on constraint
set and document type) to a file or an FADU,
o locate and erase within files.
6.19.5 Implementation Profile A2: Full File Access
Implementation Profile A2 provides the function of transfer of
and access to files with unstructured or flat constraint sets at
the external file service level. This includes support of the
document types:
o FTAM-1 "ISO FTAM unstructured text"
o FTAM-2 "ISO FTAM sequential text"
o FTAM-3 "ISO FTAM unstructured binary"
o NBS-6 "NBS-6 FTAM sequential file"
o NBS-7 "NBS-7 FTAM random access file"
o NBS-8 "NBS-8 FTAM indexed file"
This Implementation Profile supports file transfer and file
access, that is, the ability to:
o read from a complete file, or from a series of FADUs
which are identified by key or by position,
o write (replace, extend, insert depending on constraint
set and document type) to a file or an FADU,
o locate and erase within files.
6.19.6 Implementation Profile M1: Management
Implementation Profile M1 provides the function for an Initiator
to manage the files within the Virtual Filestore, to which access
is provided by the Responder. Management includes the services
of:
o creating a file
o deleting a file
o reading attributes of a file
o changing attributes of a file.
6.20 HARMONIZATION
The Implementation Profiles for File Transfer, File Access and
Management correspond to the Profiles of SPAG (Standards Promotion and
Application Group) in Europe, so that interworking will be possible.
Those Profiles are described in the 'Guide to the Use of Standards'
(GUS); they are the basis for the Functional Standards as defined by
CEN/CENELEC (Comite Europeenne de Normalization).
Table 6.8 Implementation Profiles (NBS) and Profiles (SPAG/CEN-CLC)
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 Implementation Profile SPAG/CEN-CLC 3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDBDDDDDDDDDDDDDDDDDDDDDDD4
3 3 3
3 T1 3 A/111 3
3 T2 3 A/112 3
3 T3 3 A/113 3
3 A1 3 A/122 3
3 A2 3 A/123 3
3 M1 3 A/13 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDADDDDDDDDDDDDDDDDDDDDDDDY
6.21 APPENDIX A: FTAM DOCUMENT TYPES
Part 1: Document Types
Part 2: Constraint Sets
Part 3: Abstract Syntaxes
Part 4: Intentionally Left Empty
Part 1: Document Types
NBS-6 Sequential file document type
1. Entry Number: NBS-6
2. Information objects
Table 6.9 Information objects in NBS-6
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDRDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 document type name : {iso identified-organization icd (9999) 3
3 : organization-code (1) document 3
3 : type (5) sequential (6)} 3
3 : "NBS-6 FTAM sequential file" 3
FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
3 abstract syntax names: : {iso identified-organization icd (9999) 3
3 a) name for asname1 : organization-code (1) abstract- 3
3 : syntax (2) nbs-as1 (1)} 3
3 : "NBS abstract syntax AS1" 3
3 b) name for asname2 : {iso standard 8571 abstract-syntax(2) ftam- 3
3 : fadu (2)} 3
3 : "FTAM FADU" 3
FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
3 transfer syntax names: : {joint-iso-ccitt asn1 (1) basic-encoding (1)3
3 : } "Basic Encoding of a single ASN.1 type" 3
FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMJMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
3parameter syntax: 3
3 PARAMETERS ::= SEQUENCE OF CHOICE {Parameter0, Parameter1, Parameter2} 3
3 Parameter0 ::= universal-class-number-0 [0] INTEGER {univer-time (23), 3
3 gen-time (24), 3
3 boolean (1), 3
3 null (5) } 3
3 Parameter1 ::= [1] SEQUENCE { 3
3 universal-class-number-1 INTEGER { int (2), 3
3 bit (3), 3
3 ia5 (22), 3
3 graphic (25), 3
3 general (27), 3
3 octet (4)}, 3
3 string-length INTEGER } 3
3 Parameter2 ::= [2] SEQUENCE { 3
3 private-class-number INTEGER {float (0)}, 3
3 length-1 INTEGER, 3
3 length-2 INTEGER } 3
FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMKMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
3 file model : {iso standard 8571 file-model (3) 3
3 : hierarchical (1)} 3
3 : "FTAM hierarchical file model" 3
FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
3 constraint set : {iso standard 8571 constraint-set (4) 3
3 : sequential-flat (2)} 3
3 : "FTAM sequential flat constraint set" 3
FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMJMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
3 file contents: 3
3 Datatype1 ::= PrimType -- as defined in Annex 6 A, Part 3 3
3 Datatype2 ::= CHOICE { Node-Descriptor-Data-Element, 3
3 Enter-Subtree-Data-Element , Exit- 3
3 Subtree-Data-Element} 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
3. Scope and field of application
The document type defines the contents of a file for storage, for
transfer and access by FTAM.
Note: Storage refers to apparent storage within the Virtual Filestore.
4. References
ISO 8571, Information Processing Systems - Open Systems
Interconnection - File Transfer, Access and Management
5. Definitions
This definition makes use of the terms data element, data unit and
file access data unit as defined in ISO 8571-1.
6. Abbreviations
FTAM File Transfer, Access and Management
7. Document semantics
The document consists of zero, one or more file access data units,
each of which consists of zero, one or more data elements. The order
of each of these elements is significant.
The document structure takes any of the forms allowed by the FTAM
hierarchical file model as constrained by the sequential flat
constraint set (see Table 6.9) These definitions appear in ISO 8571-
2. As additional constraints FADU identity will be limited to
'begin', 'end', 'first' and 'next'.
For a specific file the number of data elements in a data unit is
given by the parameters. Each data element is a data type from the
set of primitive data types defined in the Annex 6.A, Part 3 of this
document. Each data unit contains the same data element types in the
same order as all other data units. These types are determined by the
parameters 0 through 2.
Note: The string length values are the actual number of characters
from the specified character set, they do not include any escape
sequences or overhead from the encoding.
8. Abstract syntactic structure
The abstract syntactic structure of the document is a hierarchically
structured file as defined in the ASN.1 module ISO8571-FADU in ISO
8571, in which each of the file access data units has the abstract
syntactic structure of NBS-AS1 as defined by the parameters.
9. Definition of transfer
9.1 Datatype definitions
The file consists of data values which are of either
a) Datatype1 defined in Table 6.9, where the PrimType in
the datatype is given by the NBS-AS1 definition; or
b) Datatype2 defined in Table 6.9, the ASN.1 datatype
declared as "Data-Element" in the ASN.1 module ISO8571-
FADU.
9.2 Presentation data values
The document is transferred as a series of presentation data
values, each of which is either
a) one value of the ASN.1 datatype "Datatype1", carrying
one of the data elements from the document. All values
are transmitted in the same (but any ) presentation
context defined to support the abstract syntax name
"asname1" or
b) a value of "Datatype2". All values are transmitted in
the same (but any) presentation context defined to
support the abstract syntax name "asname2".
Notes:
1. Specific carrier standards may impose additional constraints
on the presentation context to be used, where the above
permits a choice
2. Any document type defined in this entry either makes no use
of Datatype2, or starts with a Datatype2 transmission.
Boundaries between presentation data values in the same
presentation context, and boundaries between P-DATA primitives,
are chosen locally by the sending entity at the time of
transmission, and carry no semantics of the document type.
Receivers which support this document type shall accept a
document with any of the permitted transfer options (e.g.
document type parameters and transfer syntaxes).
9.3 Sequence of presentation data values
The sequence of presentation data values of type a) and the
sequence of presentation data values of types a) and b) is the
same as the sequence of data elements within a Data Unit, and
Data Units in the hierarchical structure, when flattened
according to the definition of the hierarchical file model in ISO
8571-2.
10. Transfer syntax
An implementation supporting this document type shall support the
transfer syntax generation rules named in Table 6.9 for all
presentation data values transferred. An implementation may
optionally support other named transfer syntaxes.
11. ASE specific specifications for FTAM
11.1 Simplification and relaxation
11.1.1 Structural simplification
This simplification loses information.
The document type NBS-6 may be simplified to the document type
FTAM-3 (allowed only when reading the file). The octet
representation of the transferred data is unpredictable. It will
usually correspond to the data values as stored in the local Real
Filestore of the Responder.
11.2 Access context selection
A document of type NBS-6 may be accessed in any one of the access
contexts defined in the sequential flat constraint set. The
presentation data units transferred in each case are those
derived from the structuring elements defined for that access
context in ISO 8571-2.
11.3 The INSERT operation
When the <INSERT> operation is applied at the end of file the
transferred material shall be the series of FADUs which would be
generated by reading any NBS-6 document with the same parameter
values in access context FA.NBS-7 Random access file
1. Entry number: NBS-7
2. Information objects
Table 6.10 Information objects in NBS-7
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDRDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 document type name : {iso identified-organization icd (9999) 3
3 : organization-code (1) document 3
3 : type (5) random-file (7)} 3
3 : "NBS-7 FTAM random access file"3
FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
3 abstract syntax names: : {iso identified-organization icd (9999) 3
3 a) name for asname1 : organization-code (1) abstract- 3
3 : syntax (2) nbs-as1 (1)} 3
3 : "NBS abstract syntax AS1" 3
3 b) name for asname2 : {iso standard 8571 abstract-syntax(2) ftam- 3
3 : fadu (2)} "FTAM FADU" 3
FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
3 transfer syntax names: : {joint-iso-ccitt asn1 (1) basic-encoding (1)3
3 : } "Basic Encoding of a single ASN.1 type"3
FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMJMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
3parameter syntax: 3
3 PARAMETERS ::= SEQUENCE OF CHOICE {Parameter0, Parameter1, Parameter2} 3
3 Parameter0 ::= universal-class-number-0 [0] INTEGER {univer-time (23), 3
3 gen-time (24), 3
3 boolean (1), 3
3 null (5) } 3
3 Parameter1 ::= [1] SEQUENCE { 3
3 universal-class-number-1 INTEGER { int (2), 3
3 bit (3), 3
3 ia5 (22), 3
3 graphic (25), 3
3 general (27), 3
3 octet (4)}, 3
3 string-length INTEGER } 3
3 Parameter2 ::= [2] SEQUENCE { 3
3 private-class-number INTEGER {float (0)}, 3
3 length-1 INTEGER, 3
3 length-2 INTEGER } 3
FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMKMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
3 file model : {iso standard 8571 file-model (3) 3
3 : hierarchical (1)} 3
3 : "FTAM hierarchical file model" 3
FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
3 constraint set : {iso identified-organization icd (9999) 3
3 : organization-code (1) constraint-set (4) nbs3
3 : -ordered flat (2)} 3
3 : "NBS ordered flat constraint set" 3
FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMJMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
3 file contents: 3
3 Datatype1 ::= PrimType -- as defined in Annex 6 A, Part 3 3
3 Datatype2 ::= CHOICE { Node-Descriptor-Data-Element, 3
3 Enter-Subtree-Data-Element } 3
3 Exit-Subtree-Data-Element } 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
3. Scope and field of application
The document type defines the contents of a file for storage, for
transfer and access by FTAM.
Note: Storage refers to apparent storage within the Virtual Filestore.
4. References
ISO 8571, Information Processing Systems - Open Systems
Interconnection -File Transfer, Access and Management
5. Definitions
This definition makes use of the terms data element, data unit and
file access data unit as defined in ISO 8571-1.
6. Abbreviations
FTAM File Transfer, Access and Management
7. Document semantics
The document consists of zero, one or more file access data units,
each of which consists of zero, one or more data elements. The order
of each of these elements is significant.
The document structure takes any of the forms allowed by the FTAM
hierarchical file model as constrained by the NBS-ordered-flat
constraint set (see Table 6.10). These definitions appear in Appendix
6 A, Part 2 of this document.
For a specific file the number of data elements in a data unit is
given by the parameters. Each data element is a data type from the
set of primitive data types defined in the Annex 6.A, Part 3 of this
document. Each data unit contains the same data element types in the
same order as all other data units. These types are determined by the
parameters 0 through 2.
Note: The string length values are the actual number of characters
from the specified character set, they do not include any escape
sequences or overhead from the encoding.
8. Abstract syntactic structure
The abstract syntactic structure of the document is a hierarchically
structured file as defined in the ASN.1 module ISO8571-FADU in ISO
8571, in which each of the file access data units has the abstract
syntactic structure of NBS-AS1 as defined by the parameters.
9. Definition of transfer
9.1 Datatype definitions
The file consists of data values which are of either
a) Datatype1 defined in Table 6.10, where the PrimType in
the datatype is given by the NBS-AS1 definition; or
b) Datatype2 defined in Table 6.10, the ASN.1 datatype
declared as "Data-Element" in the ASN.1 module ISO8571-
FADU.
9.2 Presentation data values
The document is transferred as a series of presentation data
values, each of which is either
a) one value of the ASN.1 datatype "Datatype1", carrying
one of the data elements from the document. All values
are transmitted in the same (but any ) presentation
context defined to support the abstract syntax name
"asname1" or
b) a value of " Datatype2". All values are transmitted in
the same (but any) presentation context defined to
support the abstract syntax name " asname2".
Notes:
1. Specific carrier standards may impose additional constraints
on the presentation context to be used, where the above
permits a choice
2. Any document type defined in this entry either makes no use
of Datatype2, or starts with a Datatype2 transmission.
Boundaries between presentation data values in the same
presentation context, and boundaries between P-DATA primitives,
are chosen locally by the sending entity at the time of
transmission, and carry no semantics of the document type.
Receivers which support this document type shall accept a
document with any of the permitted transfer options (e.g.
document type parameters and transfer syntaxes).
9.3 Sequence of presentation data values
The sequence of presentation data values of type a) and the
sequence of presentation data values of types a) and b) is the
same as the sequence of data elements within a Data Unit, and
Data Units in the hierarchical structure, when flattened
according to the definition of the hierarchical file model in ISO
8571-2.
10. Transfer syntax
An implementation supporting this document type shall support the
transfer syntax generation rules named in Table 6.10 for all
presentation data values transferred. Implementation may
optionally support other named transfer syntaxes.
11. ASE specific specifications for FTAM
11.1 Simplification and relaxation
11.1.1 Structural simplification
This simplification loses information.
The document type NBS-7 may be accessed as a document type FTAM-3
(allowed only when reading the file) by specifying document type
FTAM-3 in the <contents type> parameter in <F-OPEN request>, and
limiting access context to UA on F-READ.
The octet representation of the transferred data is
unpredictable. It will usually correspond to the data values as
stored in the local Real Filestore of the Responder.
A document of type NBS-7 can be accessed as a document of type
NBS-6 (allowed only when reading the file) by specifying document
type NBS-6 with appropriate data type parameters in the <contents
type> parameter on the <F-OPEN request>.
11.2 Access context selection
A document of type NBS-7 may be accessed in any one of the access
contexts defined in the NBS-ordered-flat constraint set. The
presentation data units transferred in each case are those
derived from the structuring elements defined for that access
context in ISO 8571-2.
11.3 The INSERT operation
When the <INSERT> operation is applied at the end of file the
transferred material shall be the series of FADUs which would be
generated by reading any NBS-7 document with the same parameter
values in access context FA.
NBS-8 Indexed sequential file
1. Entry Number: NBS-8
2. Information objects
Table 6.11 Information objects in NBS-8
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDRDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 document type name : {iso identified-organization icd (9999) 3
3 : organization-code (1) document 3
3 : type (5) indexed-file (8)} 3
3 : "NBS-8 FTAM indexed file" 3
FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
3 abstract syntax names: : {iso identified-organization icd (9999) 3
3 a) name for asname1 : organization-code (1) abstract- 3
3 : syntax (2) nbs-as1 (1)} 3
3 : "NBS abstract syntax AS1" 3
3 b) name for asname2 : {iso standard 8571 abstract-syntax(2) ftam- 3
3 : fadu (2)} 3
3 : "FTAM FADU" 3
FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
3 transfer syntax names: : {joint-iso-ccitt asn1 (1) basic-encoding (1)3
3 : } 3
3 : "Basic Encoding of a single ASN.1 type" 3
FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMJMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
3parameter syntax: 3
3 PARAMETERS ::= SEQUENCE {DataTypes, KeyType, KeyPosition} 3
3 3
3 DataTypes ::= SEQUENCE OF CHOICE {Parameter0, Parameter1, Parameter2} 3
3 3
3 KeyType ::= CHOICE {Parameter0, Parameter1, Parameter2} 3
3 3
3 -- Parameter0, Parameter1, Parameter2, as defined for the 3
3 -- document types NBS-6, NBS-7 3
3 3
3 KeyPosition::= position INTEGER 3
FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMKMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
3 file model : {iso standard 8571 file-model (3) 3
3 : hierarchical (1)} 3
3 : "FTAM hierarchical file model" 3
FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
3 constraint set : {iso standard 8571 constraint-set (4) 3
3 : ordered-flat (3) } 3
3 : "FTAM ordered flat constraint set" 3
FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMJMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
3 file contents: 3
3 Datatype1 ::= PrimType -- as defined in Annex 6 A, Part 3 3
3 Datatype2 ::= CHOICE { Node-Descriptor-Data-Element, 3
3 Enter-Subtree-Data-Element } 3
3 Exit-Subtree-Data-Element } 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
3. Scope and field of application
The document type defines the contents of a file for storage, for
transfer and access using FTAM.
Note: Storage refers to apparent storage within the Virtual Filestore.
4. References
ISO 8571, Information Processing Systems - Open Systems
Interconnection -File Transfer, Access and Management
5. Definitions
This definition makes use of the terms data element, data unit and
file access data unit as defined in ISO 8571-1.
6. Abbreviations
FTAM File Transfer, Access and Management
7. Document semantics
The document consists of zero, one or more file access data units,
each of which consists of zero, one or more data elements. The order
of each of these elements is significant.
The document structure takes any of the forms allowed by the FTAM
hierarchical file model as constrained by the FTAM ordered flat
constraint set (see Table 6.11). These definitions appear in ISO
8571-2.
The following additional requirements are specified for the use of the
ordered flat constraint set:
o The FADU identities 'first', 'last', and 'traversal number'
are not required for conformant implementations
o The identities 'next' and 'previous' are allowed for all
FADUs
Each data element is a data type from the set of primitive data types
defined in Appendix 6A, Part 3 of this document. Each data unit
contains the same data element types in the same order as all other
data units. These types and their respective maximum lengths are
defined by the <DataTypes> parameter.
Note: The length values refer to the number of characters from the
applicable type, not to the number of octets in the encoding, nor to
the line length in any rendition of the document, where these are
different.
Each data unit in the file has a key associated with it. The key of
each data unit is of the same data type as the key of all other data
units in the file and is a single data element from the set of
primitive data types defined in Appendix 6A, Part 3.
The type and length of the key are defined by the <KeyType> parameter.
The primitive data types and minimum size ranges of each unit which an
implementation must accept as a key value are given in the following
Table 6.12.
Table 6.12 Datatypes for keys
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 Key Type Minimum Range (octets) Order 3
3 3
3 ASN.1 INTEGER (1-2) increasing numeric value 3
3 ANS.1 IA5String (0-16) lexical order 3
3 ASN.1 GraphicString (0-16) lexical order 3
3 ANS.1 GeneralString (0-16) lexical order 3
3 ANS.1 OCTET STRING (0-16) increasing value 3
3 ASN.1 GeneralizedTime increasing time value 3
3 ASN.1 UniversalTime increasing time value 3
3 NBS-AS1 FloatingPointNumber increasing numeric value 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
The position of the key in the data unit is specified by the
<position> parameter.
position = 0 implies the key is not part of the data
position > 0 specifies the actual data element in the data unit.
8. Abstract syntactic structure
The abstract syntactic structure of the document is a hierarchically
structured file as defined in the ASN.1 module ISO8571-FADU in ISO
8571, in which each of the file access data units has the abstract
syntactic structure of NBS-AS1 as defined by the parameters.
9. Definition of transfer
9.1 Datatype definitions
The file consists of data values which are of either
a) Datatype1 defined in Table 6.11, where the PrimType in the
datatype is given by the NBS-AS1 definition; or
b) Datatype2 defined in Table 6.11, the ASN.1 datatype declared
as "Data-Element" in the ASN.1 module ISO8571-FADU.
9.2 Presentation data values
The document is transferred as a series of presentation data
values, each of which is either
a) one value of the ASN.1 datatype "Datatype1", carrying one of
the data elements from the document. All values are
transmitted in the same (but any) presentation context
defined to support the abstract syntax name "asname1" or
b) a value of "Datatype2". All values are transmitted in the
same (but any) presentation context defined to support the
abstract syntax name "asname2".
Notes:
1. Specific carrier standards may impose additional constraints
on the presentation context to be used, where the above
permits a choice
2. Any document type defined in this entry either makes no use
of Datatype2, or starts with a Datatype2 transmission.
Boundaries between presentation data values in the same
presentation context, and boundaries between P-DATA primitives,
are chosen locally by the sending entity at the time of
transmission, and carry no semantics of the document type.
Receivers which support this document type shall accept a
document with any of the permitted transfer options (e.g.
document type parameters and transfer syntaxes).
9.3 Sequence of presentation data values
The sequence of presentation data values of type a) and the
sequence of presentation data values of types a) and b) is the
same as the sequence of data elements within a Data Unit, and
Data Units in the hierarchical structure, when flattened
according to the definition of the hierarchical file model in ISO
8571-2.
10. Transfer syntax
An implementation supporting this document type shall support the
transfer syntax generation rules named in Table 6.11 for all
presentation data values transferred. Implementation may
optionally support other named transfer syntaxes.
11. ASE specific specifications for FTAM
11.1 Simplification and relaxation
11.1.1 Structural simplification
This simplification loses information.
The document type NBS-8 may be accessed as a document type FTAM-3
(allowed only when reading the file) by specifying document type
FTAM-3 in the <contents type> parameter in <F-OPEN request>, and
limiting access context to UA on F-READ.
The octet representation of the transferred data is
unpredictable. It will usually correspond to the data values as
stored in the local Real Filestore of the Responder.
A document of type NBS-8 can be accessed as a document of type
NBS-6 (allowed only when reading the file) by specifying document
type NBS-6 with appropriate data type parameters in the <contents
type> parameter on the <F-OPEN request>. The traversal order of
the FADUs must be maintained.
Note: The traversal order is as reading the file as NBS-8 in key
order.
11.2 Access context selection
A document of type NBS-8 may be accessed in any one of the access
contexts defined in the FTAM ordered flat constraint set. The
presentation data units transferred in each case are those
derived from the structuring elements defined for that access
context in ISO 8571-2.
11.3 The INSERT operation
When the <INSERT> operation is applied the transferred material
shall be the series of FADU which would be generated by reading
any NBS-8 document with the same parameter values in access
context FA.
The insertion of a new FADU after an already existing FADU will
be indicated via a diagnostic on TRANSFER-END.
11.4 The EXTEND operation
This operation is excluded for the use with this document type.NBS-9 File directory file
1. Entry Number: NBS-9
2. Information objects
Table 6.12 Information objects in NBS-9
ZDDDDDDDDDDDDDDDDDDDDDDDDRDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 document type name : {iso identified-organization icd (9999) 3
3 : organization-code (1) document 3
3 : type (5) file directory (9)} 3
3 : "NBS-9 FTAM file directory file" 3
FMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
3 abstract syntax names: : {iso identified-organization icd (9999) 3
3 : organization-code (1) abstract 3
3 : syntax (2) nbs-as2 (2)} 3
3 : "NBS file directory entry abstract syntax" 3
FMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
3 transfer syntax names: : {joint-iso-ccitt asn1 (1) basic-encoding (1)}3
3 : "Basic Encoding of a single ASN.1 type" 3
FMMMMMMMMMMMMMMMMMMMMMMMMJMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
3 parameter syntax 3
3 3
3 PARAMETERS ::= attribute-names [0] IMPLICIT BIT STRING { 3
3 3
3 -- Kernel group 3
3 3
3 read_filename (0), 3
3 read_permitted-actions (1), 3
3 read_contents-type (2), 3
3 3
3 -- Storage group 3
3 3
3 read_storage-account (3), 3
3 read_date-and-time-of-creation (4), 3
3 read_date-and-time-of-last-modification (5), 3
3 read_date-and-time-of-last-read-access (6), 3
3 read_date-and-time-of-last-attribute-modification(7),3
3 read_identity-of-creator (8), 3
3 read_identity-of-last-modifier (9), 3
3 read_identity-of-last-reader (10), 3
3 read_identity-of-last-attribute-modifier (11), 3
3 read_file-availability (12), 3
3 read_filesize (13), 3
3 read_future-filesize (14), 3
3 3
3 -- Security group 3
3 3
3 read_access-control (15), 3
3 read_legal-qualifications (16), 3
3 3
3 -- Private group 3
3 3
3 read_private-use (17) } 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
(Continued on next page.)
Table 6.12 Information objects in NBS-9 continued.
ZDDDDDDDDDDDDDDDDDDDDDDDDRDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 file model : {iso standard 8571 file-model (3) 3
3 : hierarchical (1)} FTAM hierarchical file 3
3 : "FTAM hierarchical file model" 3
FMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
3 constraint-set : {iso standard 8571 constraint-set (4) 3
3 : unstructured (1)} FTAM unstructured 3
3 : "FTAM unstructured constraint set" 3
FMMMMMMMMMMMMMMMMMMMMMMMMJMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
3 File contents: 3
3 3
3 Datatype1 ::= FileDirectoryEntry 3
3 --As defined by NBS-AS2 in Appendix A, 3
3 --Part 3 of this document 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
3. Scope and field of Application
This document defines the contents of a file for transfer (not for
storage) using FTAM.
4. References
ISO 8571, Information Processing Systems - Open Systems
Interconnection -File Transfer, Access and Management.
5. Definitions
This definition makes use of the terms data element, data unit and
file access data unit as defined in ISO 8571-1
6. Abbreviations
FTAM File Transfer, Access and Management.
7. Document Semantics
The document consists of one file access data unit, which consists
only of zero, one or more data elements of type <FileDirectoryEntry>
(defined in NBS-AS2).
The document structure takes any of the forms allowed by the FTAM
hierarchical file model as constrained by the unstructured constraint
set. These definitions appear in ISO 8571-1.
The parameter of the document type is used on <F-OPEN request> to
specify the desired attributes of each of the files on the Filestore,
when reading the document.
8. Abstract syntactic structure
The abstract syntactic structure of the document is a series of file
directory entries, each of which is defined by the
<FileDirectoryEntry> definition in NBS-AS2.
Additional constraints are defined for this document type: File
access actions are restricted to Read. File-directory files may be
Selected, Opened, Read, Closed, and Deselected. They may not be
Created or Deleted. They may not be Written or Modified (except as a
side effect of actions performed on individual files contained within
a file directory).
9. Definition of transfer
9.1 Datatype definition
The file consists of zero or more values of Datatype1 defined in
Table 6.13.
9.2 Presentation data values
The document is transferred as a series of presentation data
values. Each presentation data value shall consist of one value
of the ASN.1 data type "Datatype1", carrying one of the file
directory entries from the document.
All values are transmitted in the same (but any) presentation
context established to support the abstract syntax name "asname1"
declared in Table 6.13.
9.3 Sequence of presentation data values
The sequence of presentation data values is the same as the
sequence of file directory entries within the Data Unit in the
file.
10. Transfer syntax
An implementation supporting this document type shall support the
transfer syntax generation rules named in Table 6.13 for all
presentation data values transferred. Implementations shall
optionally support other named transfer syntaxes.
11. ASE specific specifications for FTAM
11.1 Simplification and relaxation
Relaxation is allowed to any bitstring combination of the
document type parameter.
Part 2: Constraint Sets
NBS Ordered flat constraint set
1. Field of application
The NBS-ordered flat constraint set applies to files which are
structured into a sequence of individual FADUs and to which access may
be made on an FADU basis by position in the sequence.
2. Basic constraints
Table 6.14 Basic constraints for NBS Ordered flat
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDRDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 Constraint set descriptor : "NBS ordered flat constraint set" 3
FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
3 Constraint set identifier : {iso identified-organization icd (9999)3
3 : organization-code (1) 3
3 : constraint-set (4) nbs-ordered-flat(1)}3
FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
3 Node name : None 3
FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
3 File access actions : Locate, Read, Insert, Erase, Replace 3
FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
3 Qualified action : None 3
FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
3 Available access contexts : HA, FA, UA 3
FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
3 Creation state : Root node without an associated data 3
3 : unit 3
FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
3 Location after open : Root node 3
FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
3 Beginning of file : Root node 3
FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
3 End of file : No node selected; 'previous' gives last3
3 : node in traversal sequence,'current'and3
3 :'next'give an error. 3
FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
3 Read whole file : Read in access context FA or UA with 3
3 : FADU identity of 'begin'. 3
FMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMNMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM5
3 Write whole file (append) : Transfer the series of leaf FADUs which3
3 : would be generated by reading the whole3
3 : file in access context FA; perform the 3
3 : transfer with an FADU identity of 'end'3
3 : and a file access action of 'insert'. 3
3 : 3
3 Write whole file (replace) : Transfer the series of leaf FADUs which3
3 : would be generated by reading the whole3
3 : file in access-context HA; perform the 3
3 : transfer with FADU identity 'begin' and3
3 : file action of 'replace'. 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDPDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
3. Structural constraints
The root node shall not have an associated data unit; all children of
the root node shall be leaf nodes and may have an associated data
unit; all arcs from the root node shall be of length one.
4. Action constraints
Insert: The <Insert> action is allowed only at the end of file. If
the FADU identity is 'end' the new node is inserted following all
existing nodes in the file. If the FADU identity is 'traversal
number', the number must be at least one greater than the traversal
number of the last existing node. Any nodes between the last existing
node and the new node are empty, i.e. nodes without data. If the FADU
identity is a 'traversal number' not greater than that of the last
existing node, an error will occur.
Erase: The Erase action is only allowed at the root node to empty the
file, with FADU identity of 'begin'. The result is a solitary root
node without an associated data unit.
Note: It is the intention when using this constraint set to allow for
emptying an FADU, i.e. leaving an FADU with a DU of data length 0 (or
without a DU); afterwards data may be reinserted into this hole. In
order to empty an FADU, the <Replace> operation may be used with new
data of length zero (or with an FADU whose <data exists> bit is set to
'false' and no DU). Refilling the hole is accomplished by a
<Replace> operation with the new DU (or with the new FADU, whose <data
exists> bit is set to 'true' and the new DU).
5. Identity constraints
The FADU identity associated with the file action shall be one of the
identities 'begin', 'end', 'first', 'last', 'current', 'next',
'previous' or a 'traversal number' greater than or equal to one. The
actions with which these identities can be used are given in the
following table.
Table 6.15 Identity constraints in NBS Ordered flat
ZDDDDDDDDBDDDDDDDBDDDDDBDDDDDBDDDDDDBDDDDDDDBDDDDDDBDDDDDDDDBDDDDDDDDDD?
3 Action 3 Begin 3 End 3First3 Last 3Current3 Next 3Previous3Traversal 3
CDDDDDDDDEDDDDDDDEDDDDDEDDDDDEDDDDDDEDDDDDDDEDDDDDDEDDDDDDDDEDDDDDDDDDD4
3 3 3 3 3 3 3 3 3 3
3 Locate 3 valid 3valid3valid3 valid3 valid 3 valid3 valid 3 valid 3
3 3 3 3 3 3 3 3 3 3
3 Read 3 whole 3 3leaf 3 leaf 3 leaf 3 leaf 3 leaf 3 leaf 3
3 3 3 3 3 3 3 3 3 3
3 Insert 3 3valid3 3 3 3 3 3 leaf 3
3 3 3 3 3 3 3 3 3 3
3 Erase 3 whole 3 3 3 3 3 3 3 3
3 3 3 3 3 3 3 3 3 3
3 Replace3 whole 3 3leaf 3 leaf 3 leaf 3 leaf 3 leaf 3 leaf 3
3 3 3 3 3 3 3 3 3 3
@DDDDDDDDADDDDDDDADDDDDADDDDDADDDDDDADDDDDDDADDDDDDADDDDDDDDADDDDDDDDDDY
Part 3: Abstract Syntaxes
Abstract Syntax NBS-AS1
Abstract syntax name: {iso identified-organization icd (9999)
organization-code (1) abstract-syntax (2) nbs-as1
(1)}
"NBS abstract syntax AS1"
This is an abstract syntax for the set of presentation data values, each
of which is a value of the ASN.1 type NBS-AS1.PrimType
NBS-AS1 DEFINITIONS ::=
BEGIN
PrimType ::= CHOICE { INTEGER,
BIT STRING,
BOOLEAN,
IA5String,
GraphicString,
GeneralString,
OCTET STRING,
UTCTime,
GeneralizedTime,
NULL,
FloatingPointNumber }
-- The support for IA5String is the IA5 G0
-- character set and the IA5 C0 set
-- The minimum level of support for
-- GraphicString is the IA5 G0 character set and
the 8859-1 G0 and G1 sets
-- The minimum level of support for
GeneralString is the IA5 G0 character set and
the 8859-1 G0 and G1 character sets, and IA5
C0 set.
FloatingPointNumber ::= [PRIVATE 0] CHOICE {
finite [0] IMPLICIT SEQUENCE
{ Sign,
mantissa BIT STRING,
-- first bit must be 1
exponent INTEGER},
infinity [1] IMPLICIT Sign,
signalling-nan [2] IMPLICIT NaN,
quiet-nan [3] IMPLICIT NaN,
zero [4] IMPLICIT NULL }
Sign ::= INTEGER { positive (0), negative (1) }
NaN ::= INTEGER
END
For this abstract syntax the following transfer syntax can be used
{joint-iso-ccitt asn1 (1) basic-encoding (1)}
"Basic Encoding of a single ASN.1 type"
Notes: 1. The mantissa is a number in the range (1/2 <mantissa<1).
2. The value is equal to mantissa * 2 exponent.
3. The first bit in the mantissa is most significant.
4. See IEEE 754 for definitions of terminology, such as NaN.
5. A minimum length range (in bits) is required for the
components of <FloatingPointNumber>, as follows: mantissa 1-
23 bits, and exponent 0-8 bits.
Abstract Syntax NBS-AS2
Abstract syntax name: { iso identified-organization icd (9999)
organization-code (1) abstract-syntax (2)
nbs-as2 (2) }
"NBS file directory entry abstract syntax"
This is an abstract syntax for the set of presentation data values, each
of which is a value of the ASN.1 Type NBS-AS2.FileDirectoryEntry.
NBS-AS2 DEFINITIONS ::=
BEGIN
FileDirectoryEntry ::=[PRIVATE 2] Read-Attributes
Read-Attributes ::=ISO8571-FTAM.Read-Attributes
END
For this abstract syntax the following transfer syntax will be used
{ joint-iso-ccitt asn1 (1) basic-encoding (1) }
"Basic Encoding of a single ASN.1 type"
Abstract Syntax "FTAM unstructured text abstract syntax"
This abstract syntax is defined as DataType1 (File Contents) in Table 19
of ISO 8571-2, Annex B.
Abstract Syntax "FTAM unstructured binary abstract syntax"
This abstract syntax is defined as DataType1 (File Contents) in Table 21
of ISO 8571-2, Annex B.Part 4: Intentionally Left Empty
7. CCITT 1984 X.400 BASED MESSAGE HANDLING SYSTEM
7.1 INTRODUCTION
This is an implementation agreement developed by the Implementor's
Workshop sponsored by the U.S. National Bureau of Standards to promote
the useful exchange of data between devices manufactured by different
vendors. This agreement is based on, and employs protocols developed
in accord with, the OSI Reference Model. While this agreement
introduces no new protocols, it eliminates ambiguities in
interpretations.
This is an implementation agreement for a Message Handling System
(MHS) based on the X.400-series of Recommendations (1984) and Version
5 of the X.400 Series Implementor's Guide from the CCITT. It is
recommended that product vendors consult later versions of this guide.
Figure 7.1 displays the layered structure of this agreement.
This agreement can be used over any Transport protocol class. In
particular, this MHS agreement can be used over the Transport protocol
class 0 used over CCITT X.25, described in section 4.6 of this
document. In addition, this MHS agreement can be used over the
Transport profiles used in support of MAP (Manufacturing Automation
Protocol) or TOP (Technical and Office Protocols). Note that the MAP
or TOP environment must support the reduced Basic Activity Subset
(BAS) as defined in X.410.
The UAs and MTAs require access to directory and routing services. A
Directory Service is to be provided for each (vendor-specific) domain.
Except insofar as they must be capable of providing addressing and
routing described hereunder, these services and associated protocols
are not described by this agreement.
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 3
3 User Agent Layer CCITT X.420 3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3 3
3 Message Transfer Agent Layer CCITT X.411 3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3 3
3 Reliable Transfer Service Layer CCITT X.410 3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3 3
3 Presentation Layer CCITT X.410 sec. 4.2 3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3 3
3 Session Layer See Section 5.1.1 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
Figure 7.1 The layered structure of this implementation agreement
7.2 SCOPE
This agreement applies to Private Management Domains (PRMDs) and
Administration Management Domains (ADMDs). Four boundary interfaces
are specified:
(A) PRMD to PRMD;
(B) PRMD to ADMD;
(C) ADMD to ADMD.
(D) MTA to MTA (within a PRMD, e.g., for MTAs from different
vendors.)
In case A, the PRMDs do not make use of MHS services provided by an
ADMD. In cases B and C, UAs associated with an ADMD can be the source
or destination for messages. Furthermore, in cases A and B, a PRMD
can serve as a relay between MDs, and in cases B and C an ADMD can
serve as a relay between MDs. Figure 7.2 illustrates the interfaces
to which the agreement applies.
X.400 protocols other than the Message Transfer Protocol (P1) and the
Interpersonal Messaging Protocol (P2) are beyond the scope of this
agreement. Issues arising from the use of other protocols or relating
to P1 components in support of other protocols are outside the scope
of this document. This agreement describes the minimum level of
services provided at each interface shown in Figure 7.2. Provision
for the use of the remaining services defined in the X.400 Series of
Recommendations is outside the scope of this document.
With the exception of intra domain connections, this agreement does
not cover message exchange between communicating entities within a
domain even if these entities communicate via P1 or P2. Bilateral
agreements between domains may be implemented in addition to the
requirements stated in this document. Conformance to this agreement
requires the ability to exchange messages without use of bilateral
agreements.
PRMD = Private Management Domain
ADMD = Administration Management Domain ZDDDDD?
3PRMD 3
@DDBDDY
ZDDDDDDDDDDDDDD? | ---3----A
3 PRMD 3 | ZDDADD?
3 ZDDDDDDD? CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4PRMD 3
3 3 MTA A 3 3 | @DDBDDY
3 @DDDBDDDY 3 | A ---3----B
3 ---3---D 3 | ZDDADD?
3 ZDDDADDD? CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4ADMD 3
3 3 MTA B 3 3 | @DDBDDY
3 @DDDDDDDY 3 | ---3----C
@DDDDDDDDDDDDDDY B ZDDADD?
3ADMD 3
@DDDDDY
Figure 7.2 This agreement applies to the interface between: (A)
PRMD and PRMD; (B) PRMD and ADMD; (C) ADMD and ADMD;
and (D) MTA and MTA
7.3 STATUS
This version of the X.400 based Message Handling System implementation
agreements was completed on December 17, 1987. No further
enhancements will be made to this version. See the next
section--Errata.
7.4 ERRATA
7.5 PRMD to PRMD
7.5.1 Introduction
This section is limited in scope to issues arising from the direct
connection (interface A in Figure 7.2) of two PRMDs. "Direct" means
that no ADMD or relaying PRMD provides MHS services to facilitate
message interchange. "Direct" does not exclude those instances for
which Administrations happen to be ADMDs but are not providing X.400
services, that is, they are used only to provide lower layer services
such as X.25. Figure 7.3 schematically represents the scope of this
section.
These issues relate to the use of the UAL (User Agent Layer) and MTL
(Message Transfer Layer) services, protocol elements, recommended
practices and constraints. In particular, this section addresses the
P1 and P2 protocols and their related services in a direct connection
environment. This section describes the minimum level of services
provided by a PRMD. Provision for the use of the remaining services
defined in the X.400 Series of Recommendations is beyond the scope of
this section.
ZDDDDDDDDDDDDDDDDDDDD? ZDDDDDDDDDDDDDDDDDDDDD?
3 Private Domain X 3 3 Private Domain Y 3
3 3 3 3
3 3 3 3
3 3 3 3
3 3 3 3
3 ZDDDDD? 3 3 ZDDDDDD? 3
3 ZD>3 UA 3<DDDDDDEDDDDDDDDDDDDD P2 DDDDDDDDDDDDDDDDEDDDD>3 UA 3<D? 3
3 3 CDDDDD4 3 3 CDDDDDD4 3 3
3 3 3 MTA 3<DDDDDDEDDDDDDDDDDDDD P1 DDDDDDDDDDDDDDDDEDDDD>3 MTA 3 3 3
3 3 @DDDDDY 3 3 @DDDDDDY 3 3
3 3 /3\ 3 3 /3\ 3 3
3 3 3 3 3 3 3
3 000000000000000 3 3 00000000000000 3
3 0the00000000000 3 3 0the0000000000 3
3 0remainder of00 3 3 0remainder of0 3
3 0Domain X000000 3 3 0Domain Y00000 3
3 0NETWORK0000000 3 3 0NETWORK000000 3
3 000000000000000 3 3 00000000000000 3
@DDDDDDDDDDDDDDDDDDDDY @DDDDDDDDDDDDDDDDDDDDDY
Figure 7.3 Interconnection of private domains
7.5.2 Service Elements and Optional User Facilities
This section identifies those service elements and optional user
facilities that must be provided in support of P1 and P2.
7.5.2.1 Classification of Support for Services
The classification of UA and MT-Service elements is used to
define characteristics of equipment. Equipment can claim
SUPPORT or NON-SUPPORT of a Service; in the case of
UA-service elements, a separate classification is given for
Origination and Reception.
The service provider is defined as the entity providing the
service, in this case, the MTL or the UAL. The service user
is either the MHS user or the UAL. The classification of
provider and user relates to the sublayer for which the
service element is defined.
7.5.2.1.1 Support (S)
a) Support means:
o The service provider makes the service
element available to the service user.
o The service user gives adequate support to
the MHS to invoke the service element or
makes information associated with the service
element available.
b) Support for Origination means that:
o The service provider makes the service
element available to the service user for
invocation.
o The service user gives adequate support to
the end user of the MHS to invoke the service
element.
c) Support for Reception means that:
o The service provider makes information
associated with the service element available
to the service user.
Note: A UA- or MT-service element can carry
information from originator to recipient only if:
o the service element is available to the
originator,
o the service element is available to the
recipient, and
o all intermediate steps carry the information.
7.5.2.1.2 Non Support (N)
This means that the service provider is not required to
make the service element available to the service user.
However, the service provider should not regard the
occurrence of the corresponding protocol elements as an
error and should be able to relay such elements.
Implementations making a profile available should
indicate deviations (additions or deletions) with
respect to the requirement in the profile.
7.5.2.1.3 Not Used (N/U)
This means that although the Recommendation allows this
service element, this profile does not use it.
7.5.2.1.4 Not Applicable (N/A)
This means that this service element does not apply in
this particular case (for originator or recipient).
7.5.2.2 Summary of Supported Services
a) Within a PRMD, a User Agent must support all P2 BASIC
IPM Services (X.400) and all P2 ESSENTIAL IPM Optional
user facilities (X.401) subject to the qualifiers
listed in Appendix 7A.
b) Within a PRMD, a MTA must support all BASIC MT Services
(X.400) and all ESSENTIAL MT optional user facilities
(X.401) subject to the qualifiers listed in Appendix
7A.
c) No support is required of the additional optional user
facilities of X.401.
7.5.2.3 MT Service Elements and Optional User Facilities
Tables 7.1 through 7.3 show the message transfer (MT)
service elements and optional user facilities.
Table 7.1 Basic MT service elements
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 Support (S) or 3
3 Service Elements Non-support (N) 3
3 3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3 Access Management N/U1 3
3 Content Type Indication S 3
3 Converted Indication S 3
3 Delivery Time Stamp Indication S 3
3 Message Identification S 3
3 Non-delivery Notification S 3
3 Original Encoded Information Types Indication S 3
3 Registered Encoded Information Types N/U1 3
3 Submission Time Stamp Indication S 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
DDDDDDDDDDDDDDDD
1 Not applicable to co-resident UA and MTA.
Table 7.2 MT optional user facilities provided to the UA-selectable on a
per-message basis
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 3
3 Support (S) or 3
3 MT Optional User Facilities Categorization Non-support (N) 3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3 3
3 Alternate Recipient Allowed E S 3
3 Conversion Prohibition E S 3
3 Deferred Delivery E N2 3
3 Deferred Delivery Cancellation E N2 3
3 Delivery Notification E S 3
3 Disclosure of Other Recipients E N3 3
3 Explicit Conversion A N 3
3 Grade of Delivery Selection E S 3
3 Multi-destination Delivery E S 3
3 Prevention of Non-delivery Notification A N 3
3 Probe E N4 3
3 Return of Contents A N 3
3 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
Table 7.3 MT optional user facilities provided to the UA agreed for
any contractual period of time
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 Support (S) or 3
3 MT Optional User Facilities Categorization Non-Support (N)3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3 3
3Alternate Recipient Assignment A N 3
3Hold for Delivery A N/U 3
3Implicit Conversion A N 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
DDDDDDDDDDDDD
E: Essential optional user facility.
A: Additional optional user facility.
2 A local facility subject to qualifiers in Appendix 7A.
3 Support not required for an originating MT user; support must be
provided for recipient MT users.
4 Subject to qualifiers in Appendix 7A.
7.5.2.4 IPM Service Elements and Optional User Facilities
Tables 7.4 through 7.5 show the IPM service elements and
optional user facilities.
Table 7.4 Basic IPM service elements
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 3
3 Origination Reception 3
3 Service Elements by UAs by UAs 3
3 3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3Access Management N/U5 N/U5 3
3Content Type Indication S S 3
3Converted Indication N/A S 3
3Delivery Time Stamp Indication N/A S 3
3Message Identification S S 3
3Non-delivery Notification S N/A 3
3Original Encoded Information S S 3
3 Types Indication 3
3Registered Encoded Information Types N/A N/A5 3
3Submission Time Stamp Indication S S 3
3IP-message Identification S S 3
3Typed Body S S 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
5 Does not apply to co-resident UA and MTA.
Table 7.5 IPM optional facilities agreed for a contractual period of
time
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 3
3 Support (S) or 3
3 Service Elements Categorization Non-Support (N)3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3Alternate Recipient Assignment A N 3
3Hold for Delivery A N 3
3Implicit Conversion A N 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
Table 7.6 IPM optional user facilities selectable on a per-message basis
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 3
3 Origination Reception3
3 IPM Optional User Facilities by UAs by UAs 3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3Alternate Recipient Allowed A (N) A (N)3
3Authorizing Users Indication A (N) E (S)3
3Auto-forwarded Indication A (N) E (S)3
3Blind Copy Recipient Indication A (N) E (S)3
3Body Part Encryption Indication A (N) E (S)3
3Conversion Prohibition E (S) E (S)3
3Cross-referencing Indication A (N) E (S)3
3Deferred Delivery E (N)6 N/A 3
3Deferred Delivery Cancellation A (N/U)6 N/A 3
3Delivery Notification E (S) N/A 3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3Disclosure of Other Recipients A (N) E (S)3
3Expiry Date Indication A (N) E (S)3
3Explicit Conversion A (N) N/A 3
3Forwarded IP-message Indication A (N) E (S)3
3Grade of Delivery Selection E (S) E (S)3
3Importance Indication A (N) E (S)3
3Multi-destination Delivery E (S) N/A 3
3Multi-part Body A (N) E (S)3
3Non-receipt Notification A (N) A (N)3
3Obsoleting Indication A (N) E (S)3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3Originator Indication E (S) E (S)3
3Prevention of Non-delivery Notification A (N) N/A 3
3Primary and Copy Recipients Indication E (S) E (S)3
3Probe A (N) N/A 3
3Receipt Notification A (N) A (N)3
3Reply Request Indication A (N) E (S)3
3Replying IP-message Indication E (S) E (S)3
3Return of Contents A (N) N/A 3
3Sensitivity Indication A (N) E (S)3
3Subject Indication E (S) E (S)3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
DDDDDDDDDDD
6 A local facility subject to qualifiers in Appendix 7A.
7.5.3 X.400 Protocol Definitions
This section reflects the agreements of the NBS/OSI Workshop
regarding P1 and P2 protocol elements.
7.5.3.1 Protocol Classification
The protocol classifications are defined below in table
7.7:
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 1) UNSUPPORTED = X 3
3 These elements may be generated, but no specific processing should 3
3 be expected in a relaying or delivering domain. A relaying domain 3
3 must at least relay the semantics of the element. The absence of 3
3 these elements should not be assumed, in a relaying or delivering 3
3 domain, to convey any significance. 3
3 3
3 2) SUPPORTED = H 3
3 These elements may be generated. However, implementations are not 3
3 required to be able to generate these elements. Appropriate 3
3 actions shall be taken in a relaying or delivering domain. 3
3 3
3 3) GENERATABLE = G 3
3 Implementations must be able to generate and handle these protocol 3
3 elements, although they are not necessarily present in all 3
3 messages generated by implementations of this profile. 3
3 Appropriate actions shall be taken in a relaying or delivering 3
3 domain. 3
3 3
3 4) REQUIRED = R 3
3 Implementations of this profile must always generate this protocol 3
3 element. However, its absence cannot be regarded as a protocol 3
3 violation as other MHS implementations may not require this 3
3 protocol element. Appropriate actions shall be taken in a 3
3 relaying or delivering domain. 3
3 3
3 5) MANDATORY = M 3
3 This must occur in each message as per X.411 or X.420 as 3
3 appropriate; absence is a protocol violation. Appropriate actions 3
3 shall be taken in a relaying or delivering domain. 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
Table 7.7 Protocol Classifications
7.5.3.2 General Statements on Pragmatic Constraints
a) Where a protocol element is defined as a choice of
Numeric String and Printable String (i.e.,
Administration Domain Name and Private Domain
Identifier), then a numeric value encoded as a
printable string is equivalent to the same value
encoded as a numeric string. This does not apply to
the Country Name protocol element.
b) The maximum number of recipients in a single MPDU is
32K - 1 (that is, 32767). However, no individual
limits on the number of occurrences (recipients) are
placed on the following protocol elements: Authorizing
Users, Primary Recipients, Copy Recipients, Blind Copy
Recipients, Obsoletes and Cross References.
Additionally, there is no limit on the number of Reply
to Users. This is a local matter for the originating
system.
c) Use of strings. A Printable String is defined in terms
of the number of characters, which is the same number
of octets. For T.61 strings the number of octets is
twice the number of characters specified.
d) The ability to generate maximum size elements is not
required, with the exception of the component fields in
the Standard Attribute List, in which case it is
required.
7.5.3.3 MPDU Size
The following agreements govern the size of MPDUs:
o All MTAEs must support at least one MPDU of at least
two megabyte.
o The size of the largest MPDU supported by a UAE is a
local matter.
7.5.3.4 P1 Protocol Elements
7.5.3.4.1 P1 Envelope Protocol Elements
Table 7.8 contains Protocol Elements and their
classes.
Table 7.8 P1 protocol elements
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3Element Class Restrictions and Comments 3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3MPDU 3
3 UserMPDU G 3
3 DeliveryReportMPDU G 3
3 3
3 ProbeMPDU H 3
3 3
3UserMDPU 3
3 UMPDUEnvelope M 3
3 UMPDUContent M 3
3 3
3UMPDUEnvelope 3
3 MPDUIdentifier M 3
3 originator ORname M 3
3 originalEncodedInformationTypes G 3
3 If this field is absent, then the 3
3 Encoded Information Type is 3
3 "unspecified". 3
3 ContentType M 3
3 UAContentID H Maximum length = 16 characters. 3
3 Priority G 3
3 PerMessageFlag G Maximum length = 2 octets. 3
3 deferredDelivery X 3
3 PerDomainBilateralInfo X No limit on number of occurrences. 3
3 RecipientInfo M Maximum number = 32K - 1 occurr- 3
3 ences. More severe limitations are 3
3 by bilateral agreement. 3
3 TraceInformation M 3
3UMPDUContent M 3
3 3
3MPDUIdentifier 3
3 GlobalDomainIdentifier M 3
3 IA5String M Maximum length = 32 characters, 3
3 graphical subset only. Refer to 3
3 T.50 for clarification of graphical3
3PerMessageFlag subset. 3
3 discloseRecipients H 3
3 conversionProhibited G 3
3 alternateRecipientAllowed H 3
3 contentReturnRequest X 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
(Continued on next page.)
Table 7.8 P1 protocol elements, Continued
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3Element Class Restrictions and Comments 3
3 3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3PerDomainBilateralInfo 3
3 CountryName M Maximum length = 3 characters. 3
3 AdministrationDomainName M Maximum length = 16 characters. 3
3 BilateralInfo M Maximum depth = 8; maximum 3
3 length = 1024 octets 3
3 (including encoding). 3
3 RecipientInfo 3
3 recipient M 3
3 ExtensionIdentifier M Maximum value = 32K - 1 (32767). 3
3 perRecipientFlag M Maximum length = 2 octets. 3
3 ExplicitConversion X 3
3 3
3perRecipientFlag 3
3 ResponsibilityFlag M 3
3 ReportRequest M 3
3 UserReportRequest M 3
3 3
3TraceInformation Reference should be made to 3
3 Version 5 of the X.400 Imple- 3
3 mentor's Guide for information 3
3 GlobalDomainIdentifier M related to Trace sequencing. 3
3 DomainSuppliedInfo M 3
3 3
3DomainSuppliedInfo 3
3 arrival M 3
3 deferred X 3
3 action M 3
3 0=relayed (value) G 3
3 1=rerouted (value) H Rerouting is not required. 3
3 converted H 3
3 previous H 3
3 3
3ORName See section 7.5.3.5 3
3 3
3EncodedInformationTypes 3
3 bit string M Delivery can only occur if match 3
3 is made with Registered Encoded 3
3 Information Types. Individual 3
3 vendors may impose limits. 3
3 Maximum length = 4 octets. 3
3 G3NonBasicParameters X 3
3 TeletexNonBasicParameters X 3
3 PresentationCapabilities X 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
(Continued on next page.)
Table 7.8 P1 protocol elements, Continued
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 3
3Element Class Restrictions and Comments 3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3 3
3DeliveryReportMPDU 3
3 DeliveryReportEnvelope M 3
3 DeliveryReportContent M 3
3 3
3 3
3 3
3DeliveryReportEnvelope 3
3 report M 3
3 originator M 3
3 TraceInformation M 3
3 3
3DeliveryReportContent 3
3 original M 3
3 intermediate G See comment at end of table. 3
3 UAContentID G 3
3 ReportedRecipientInfo M Maximum number = 32K - 1 3
3 occurrences. 3
3 returned H Can only be issued if specifically 3
3 requested in the originating 3
3 message. 3
3 billingInformation X Maximum depth = 8; maximum 3
3 length = 1024 octets (including 3
3 encoding). 3
3 3
3 3
3ReportedRecipientInfo 3
3 recipient M 3
3 ExtensionsIdentifier M 3
3 PerRecipientFlag M 3
3 LastTraceInformation M 3
3 intendedRecipient H 3
3 SupplementaryInformation X Maximum length = 64 characters. 3
3 Value is pending verification by 3
3 the CCITT SG VIII or XI. 3
3 3
3 3
3 3
3 3
3LastTraceInformation 3
3 arrival M 3
3 converted G 3
3 Report M 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
(Continued on next page.
Table 7.8 P1 protocol elements, continued
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 3
3Element Class Restrictions and Comments 3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3Report 3
3 DeliveredInfo G Generated if delivery is reported. 3
3 NondeliveredInfo G Generated if failure to deliver 3
3 is reported. 3
3DeliveredInfo 3
3 delivery M 3
3 typeofUA R This element must be generated with3
3 a PRIVATE value by PRMDs. 3
3 3
3NonDeliveredInfo 3
3 ReasonCode M 3
3 DiagnosticCode H Whenever possible, use a meaningful3
3 diagnostic code. 3
3 3
3ProbeEnvelope 3
3 probe M 3
3 originator M 3
3 ContentType M 3
3 UAContentID H Maximum length = 16 characters. 3
3 original G If this field is absent, then the 3
3 Encoded Information Type is 3
3 "unspecified". 3
3 3
3 3
3 TraceInformation M 3
3 3
3 PerMessageFlag G 3
3 3
3 contentLength H 3
3 PerDomainBilateralInfo X 3
3 RecipientInfo M Maximum number = 32K - 1 3
3 occurrences. 3
3GlobalDomainIdentifier 3
3 CountryName M Maximum length = 3 characters. 3
3 AdministrationDomainName (4) M Maximum length = 16 characters or 3
3 digits. 3
3 3
3 PrivateDomainIdentifier R Maximum length = 16 characters or 3
3 digits. This element must be 3
3 generated by PRMDs. 3
3 3
3 End of Definitions 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
Notes on Table 7.8
Comment on intermediate TraceInformation in the
DeliveryReportContent in table 7.8: Audit and confirmed reports
should not be requested by other than the originating domain for
two reasons. First, the return path of the report may be
different from the path taken by the original message, and it may
exclude the domain that added the request for audit and confirmed
to the message. Second, if the return path is different from the
path of the original message, the originating domain would
receive intermediate trace information that it did not request.
7.5.3.5 ORName Protocol Elements
Only form 1 variant 1 O/R names are supported.
Table 7.9 contains ORName protocol elements.
These agreements interpret 1984 X.400 Section 3.4 to mean
that the attributes in the ORName in the MPDU must identify
exactly one UA, and that all the values for the attributes
specified in the ORName must be identical to the values of
the corresponding attributes associated with the recipient
UA. Underspecified names that are unique are deliverable.
Overspecified ORNames, ORNames with mismatching fields, and
ambiguous names are to be non-delivered or sent to the
alternate recipient as appropriate.
Table 7.9 ORName protocol elements
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3Element Class Restrictions and Comments 3
3 3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3 3
3ORName 3
3 StandardAttributeList M 3
3 DomainDefinedAttributeList X 3
3 3
3StandardAttributeList (1) 3
3 CountryName R As defined in X.411, Maximum 3
3 length = 3 characters. 3
3 AdministrationDomainName (4) R Maximum length = 16 characters 3
3 or digits. 3
3 X121Address X Maximum length = 15 digits. 3
3 TerminalID X Maximum length = 24 characters. 3
3 PrivateDomainName (2) G Maximum length = 16 characters. 3
3 OrganizationName (2) G Maximum length = 64 characters. 3
3 UniqueUAIdentifier X Maximum length = 32 digits. 3
3 PersonalName G Maximum length of values of sub- 3
3 elements = 64 characters. 3
3 Note: The possibility that this 3
3 value may be reduced to 40 3
3 characters is for further 3
3 study by the CCITT. 3
3 3
3 OrganizationalUnit (3) G Maximum length = 32 characters per 3
3 occurrence. A maximum of four 3
3 occurrences are allowed. 3
3 3
3DomainDefinedAttributeList (5) Maximum = 4 occurrences. 3
3 type M Maximum length = 8 characters. 3
3 value M Maximum length = 128 characters. 3
3 3
3PersonalName 3
3 surName M Maximum length = 40 characters. 3
3 givenName G Maximum length = 16 characters. 3
3 initials G Maximum length = 5 characters; 3
3 excluding surname initial and 3
3 punctuation and spaces. 3
3 generationQualifier G Maximum length = 3 characters. 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
(Continued on next page.)
Table 7.9 ORName Protocol Elements, Continued
Notes:
1. The following apply for comparison of the Standard Attributes of
an O/R Name:
a. Lower case is interpreted as upper case (for IA5).
b. Multiple spaces may be interpreted as a single space.
Originating domains shall only transmit single
significant spaces. If multiple spaces are transmitted,
non-delivery may occur.
2. At least one of these must be supplied.
3. These should be sent in ascending sequence, from the least
significant <Organizational Unit> (lowest in organization
hierarchy) to the most significant. Only those specified should
be sent. (That is, an unspecified <Organizational Unit> should
not be sent along as a field of [null] content, nor zero length,
etc.)
4. This attribute shall contain one space in all ORNames of messages
originated in a PRMD that is not connected to an ADMD, and in
ORNames of recipients reachable only through a PRMD; otherwise,
this attribute shall contain an appropriate ADMD name.
5. Some existing systems which will be accessed via an X.400 service
(whether directly connected using X.400 protocols or otherwise)
may require the provision of addressing attributes which are not
adequately supported by Standard Attributes as defined in these
Agreements. In such cases, Domain Defined Attributes are an
acceptable means of carrying additional addressing information.
Failure to support the specification and relaying of DDAs may
prevent successful interworking with such existing systems until
such time as all systems are capable of relaying and delivery
using only the Standard Attribute list. Specific recommendations
on the use of DDAs for particular applications are in the
Recommended Practices Section 7.12, Appendix B.
7.5.3.6 P2 Protocol Profile (Based on [X.420])
Tables 7.10 and 7.11 classify the support for the P2
protocol elements required by this profile. The tables
give restrictions and comments in addition to X.420.
Restriction on length is one of the types of restrictions.
The reaction of implementations to a violation of this
restriction is not defined by this Profile.
7.5.3.6.1 P2 Protocol - Heading
Table 7.10 below specifies the support for protocol
elements in P2 Headings.
Table 7.10 P2 heading protocol elements
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 Element Class Restrictions and Comments 3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3UAPDU 3
3 IM-UAPDU G 3
3 SR-UAPDU X 3
3 3
3IM-UAPDU 3
3 Heading M 3
3 Body M 3
3 3
3Heading 3
3 IPMessageId M 3
3 originator R 3
3 authorizingUsers H 3
3 primaryRecipients G At least one of primaryRecipients, 3
3 copyRecipients G copyRecipients, or 3
3 blindCopyRecipients must be 3
3 blindCopyRecipients H present. 3
3 inReplyTo G 3
3 obsoletes H 3
3 crossReferences H 3
3 subject G Maximum length = 128 T.61 3
3 characters (256 octets);the ability3
3 to generate the maximum size 3
3 subject is not required. 3
3 expiryDate H 3
3 replyBy H 3
3 replyToUsers H 3
3 importance H Appropriate action is for further 3
3 study. 3
3 sensitivity H Appropriate action is for further 3
3 study. 3
3 autoforwarded H 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
(Continued on next page.)
Table 7.10 P2 heading protocol elements, continued
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3Element Class Restrictions and Comments 3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3 3
3IPmessageId 3
3 ORName H 3
3 PrintableString M Maximum length = 64 characters. 3
3ORDescriptor 3
3 ORName H Specify the ORName whenever it is 3
3 possible. See Appendix 7B. 3
3 freeformName H Maximum length = 64 characters, 3
3 graphical subset only (128 octets.)3
3 telephoneNumber H Maximum length = 32 characters. 3
3 This allows for punctuation. It 3
3 does not take into account possible3
3 future use by ISDN. 3
3 3
3Recipient 3
3 ORDescriptor M 3
3 reportRequest X 3
3 replyRequest H 3
3 3
3Body No limit on number of BodyParts. 3
3 BodyPart G No limit on length of any BodyPart 3
3 or the depth of ForwardedIPMessage 3
3 BodyParts nested. Classification is3
3 subject to pending CCITT resolution3
3 3
3 3
3SR-UAPDU 3
3 nonReceipt H 3
3 receipt H 3
3 reported M 3
3 actualRecipient R 3
3 intendedRecipient H 3
3 converted X 3
3NonReceiptInformation 3
3 reason M 3
3 nonReceiptQualifier H 3
3 comments H Maximum length = 256 characters. 3
3 returned H May only be issued if specifically 3
3 requested by originator. 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
(Continued on next page.)
Table 7.10 P2 heading protocol elements, continued
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3Element Class Restrictions and Comments 3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3 3
3ReceiptInformation 3
3 receipt M 3
3 typeOfReceipt H 3
3 SupplementaryInformation X Maximum length = 64 characters. 3
3 Note: This value is pending 3
3 verification by the CCITT SG 3
3 VIII or IX. 3
3 3
3 End of Definitions 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
7.5.3.6.2 P2 Protocol - BodyParts
a) All BodyParts with identifiers in the range 0 up
to and including 16K -1 are legal and should be
relayed. BodyPart identifiers corresponding to
X.121 Country Codes should be interpreted as
described in Note 2 of figure 7.4.
o Implementations are required to generate and
image IA5Text.
o Implementations should specify the other
BodyPart types supported.
o If an implementation supports a particular
BodyPart type for reception, it should also
be able to support that BodyPart type for
reception if it is part of a
ForwardedIPMessage.
o For the BodyPart types currently considered,
support for the protocol elements is as
indicated in table 7.11.
b) Privately Defined BodyParts
This section describes an interim means for
identifying privately defined BodyParts. This
section shall be replaced in a future version
taking into account CCITT recommendations with
equivalent functionality.
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 BodyPart :: = CHOICE { 3
3 [0]IMPLICIT IA5Text, 3
3 [1]IMPLICIT TLX, 3
3 . 3
3 . 3
3 . 3
3 [234]IMPLICIT UKBodyParts, 3
3 . 3
3 . 3
3 . 3
3 [310]IMPLICIT USABodyParts, 3
3 . 3
3 . 3
3 . } 3
3 Where UKBodyParts and USABodyParts are defined as: 3
3 3
3 SEQUENCE {BodyPartNumber, ANY} 3
3 3
3 BodyPartNumber ::= INTEGER 3
3 3
3 3
3 3
3 3
3 3
3 Note 1: In the EncodedInformationTypes of the P1 Envelope, the 3
3 undefined bit must be set when a message contains a 3
3 privately defined BodyPart. Each UA that expects such 3
3 BodyParts should include undefined in the set of 3
3 deliverable EncodedInformationTypes it registers with the 3
3 MTA. 3
3 3
3 Note 2: All BodyPartNumbers assigned must be interpreted relative 3
3 to the BodyPart in which they are used, which is that 3
3 tagged with the value [310] for those defined within the 3
3 United States. The NBS assigns unique message 3
3 BodyPartNumbers for privately defined formats within the 3
3 United States. 3
3 3
3 Note 3: Refer to section 7.12.6 for recommendations regarding the 3
3 implementaion of USABodyParts. 3
3 3
3 3
3 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
Figure 7.4 X.409 Definition of Privately Defined BodyParts
7.5.3.6.3 P2 BodyPart Protocol Elements
Table 7.11 P2 BodyParts
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3Elements Class Restrictions and Comments 3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3 3
3BodyPart 3
3 IA5Text G 3
3 TLX X 3
3 Voice X 3
3 G3Fax X 3
3 TIFO X 3
3 TTX X 3
3 Videotex X 3
3 NationallyDefined X 3
3 Encrypted X 3
3 ForwardedIPMessage H 3
3 SFD X 3
3 TIF1 X 3
3 unidentified X 3
3 3
3IA5Text 3
3 repertoire H 3
3 IA5String M For rendition of IA5Text see 3
3 Appendix 7C. 3
3TLX For further study by CCITT. 3
3 3
3Voice 3
3 Set For further study by CCITT. 3
3 BitString M 3
3 3
3G3Fax 3
3 numberOfPages X 3
3 P1.G3NonBasicParameters X 3
3 SEQUENCE (OF BIT STRING) M 3
3 BIT STRING H See Note. 3
3 3
3P1.G3NonBasicParameters Support for individual elements is 3
3 for further study. 3
3 3
3TIFO 3
3 T.73Document M 3
3 T.73ProtocolElement H See Note. 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
(Continued on next page.)
Table 7.11 P2 BodyParts, continued
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3Elements Class Restrictions and Comments 3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3 3
3TTX 3
3 numberOfPages X 3
3 telexCompatible X 3
3 P1.TeletexNonBasicParams X 3
3 SEQUENCE M 3
3 T61String H See Note. 3
3 3
3P1.TeletexNonBasicParams 3
3 graphicCharacterSets X 3
3 controlCharacterSets X 3
3 pageFormats X 3
3 miscTerminalCapabilities X 3
3 privateUse X 3
3 3
3Videotex 3
3 SET For further study by CCITT. 3
3 VideotexString M 3
3 3
3NationallyDefined 3
3 ANY M 3
3 3
3Encrypted 3
3 SET For further study by CCITT. 3
3 BIT STRING M 3
3 3
3ForwardedIPMessage 3
3 delivery H 3
3 DeliveryInformation H 3
3 IM-UAPDU M 3
3 3
3DeliveryInformation 3
3 P1.ContentType M 3
3 originator M 3
3 original M 3
3 P1.Priority G 3
3 DeliveryFlags M 3
3 otherRecipients H 3
3 thisRecipient M 3
3 intendedRecipient H 3
3 converted X 3
3 submission M 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
(Continued on next page.)
Table 7.11 P2 BodyParts, continued
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3Elements Class Restrictions and Comments 3
3 3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3SFD 3
3 SFD.Document M 3
3 3
3TIF1 3
3 T73 Document M 3
3 T73.ProtocolElement H See note. 3
3 DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD 3
3 3
3Note: This element is not an addition to the definition of the BodyPart. 3
3 It is described here to show that the SEQUENCE may contain zero 3
3 elements. A Problem Report has been submitted to the CCITT to 3
3 clarify whether this is permissible. The NBS/OSI Workshop will 3
3 adopt the CCITT decision. 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
7.5.4 Reliable Transfer Server (RTS)
7.5.4.1 Implementation Strategy
Based on X.410 clause 3 and X.411 clause 3.5.
7.5.4.2 RTS option selection
a) The maximum number of simultaneous associations is not
limited in this profile; if the capacity of a system is
exceeded, it should not initiate or accept additional
associations.
b) Associations are established by the MTA which has
messages to transfer.
c) Associations are released when they are not needed.
Associations may also be ended prematurely due to
internal problems of the RTS.
d) For both monologue and two way alternate associations,
the initiator keeps the initial turn.
e) When establishing an RTS association, the following
rules apply to the use of parameters in addition to
those in X.410 clause 3.2.1:
Dialogue mode: Monologue must be supported for this
profile; two-way alternate is used only
if both partners agree.
Initial turn: Kept by the initiator of the
association.
f) The 'priority-mechanism' and the 'transfer-time limit'
are regarded as local matters.
7.5.4.3 RTS Protocol Options and Clarifications
Realization of the RTS protocol is subject to the following
rules in addition to those specified in X.410 clause 4:
a) One RTS association corresponds to one or more
consecutive session connections (not concurrent ones).
The first is opened with ConnectionData of type OPEN,
and subsequent ones are opened with type RECOVER.
b) Recovery of a Session connection is only by RTS
initiator.
c) Checkpoint size:
o Checkpointing and No Checkpointing should be
supported. Whenever possible, checkpointing
should be used.
o The minimum checkpointSize is 1 (that is, 1024
octets).
d) Window size:
o Minimal value of 1 (if checkpointing is
supported).
o WindowSize = 1 means: After an S-SYNCH-MINOR
request is sent, wait until the confirmation is
received before issuing an S-DATA, S-SYNCH-MINOR,
or S-ACTIVITY-END request.
e) APDUs should not be blocked into one activity.
f) Only one SSDU shall be transferred:
o Between two adjacent minor synch points.
o Between minor synch points and adjacent
S-ACTIVITY-START and S-ACTIVITY-END requests.
o Between S-ACTIVITY-START and S-ACTIVITY-END
without checkpoints.
g) A monologue association is defined as follows:
o The RTS user responsible for establishing the
association is called the initiator.
o The initiator keeps the initial turn.
o APDUs are transferred in the direction of the
initiator to the recipient only.
o There shall be no token passing.
o Only the initiator can effect an orderly release
of the association.
h) A two-way alternate association is as described in
X.410.
i) In the UserData parameter of the S-U-ABORT, the
ReflectedParameter will not be used in the
AbortInformation element.
j) When the S-ACTIVITY-RESUME is used to resume an
activity in the same session connection as the one in
which it started, this must happen immediately after
the activity has been interrupted (i.e., no intervening
activity can occur). Otherwise, X.410 clause 4.3
paragraph 1 may be violated.
k) When S-ACTIVITY-RESUME is used to resume an activity
started in another session connection, the following
conditions must be met:
o The current session connection is of type
"recover".
o The value of OldSessionConnectionIdentifier in
S-ACTIVITY-RESUME must match the value of the
SessionConnectionIdentifier parameter used in the
S-CONNECT of the prior session connection. This
value is also identical to the
SessionConnectionIdentifier in the ConnectionData
(in PConnect, in SS-UserData) for the current
session connection.
o This must occur as the first activity of the next
session connection for the same RTS-association.
It must be the first, otherwise X.410 clause 4.5.1
point 1 is violated.
Note: It is in the same RTS-ASSOCIATION because the use of
S-ACTIVITY-RESUME only makes sense within the scope of one
RTS association.
l) If the transfer of an APDU is interrupted before the
confirmation of the first checkpoint, the value of the
SynchronizationPointSerialNumber in S-ACTIVITY-RESUME
should be zero, and the S-ACTIVITY-RESUME must be
immediately followed by an S-ACTIVITY-DISCARD.
m) In S-TOKEN-PLEASE, the UserData parameter shall contain
an integer conforming to X.409 which conveys the
priority.
n) The receiving RTS can use the value of the Reason
parameter in the S-U-EXCEPTION-REPORT to suggest to the
sending RTS that it should either interrupt or discard
the current activity. S-U-Exception Reports are
handled as stated in Version 5 of the Implementors
Guide pages 12-13, paragraph E-33.
o) In the case of S-P-ABORT, the current activity (if any)
is regarded as interrupted, rather than discarded.
p) Table 7.12 illustrates the legal negotiation
possibilities allowed by X.410 clause 4.2.1 regarding
checkpoint size and window size.
q) These agreements include the provisions of version 6 of
the Implementors Guide identical in all respects to
version 5, except that the following points have been
added to section 3.5:
o for section 4.4.1 of X.410;
"If the receiving RTS receives an S-ACTIVITY-DISCARD
indication primitive and has already issued a TRANSFER
indication primitive, it aborts the connection (S-U-ABORT
request) with the "transfer completed" version code."
o for section 4.6.2 of X.410
"The "transfer completed (7)" abort reason is used to
indicate to the sending RTS that the receiving RTS could not
discard the activity because it has already completed the
transfer (issued a TRANSFER indication primitive)."
Transfer completed (7) is also added to the table of abort
reasons in this section.
Table 7.12 Checkpoint window size of IP
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 acceptor answer 3
CDDDDDDDDDDDDDDDDBDDDDDDDDDDDDDDDDBDDDDDDDDDDDDDDDD4
3 CS = 0 3 CS = m 3 CS = n 3
3(or unspecified)3 WS = j 3 WS = j 3
3 WS unspecified 3(or unspecified)3(or unspecified)3
ZDDDDDDDDDBDDDDDDDDDDDDDDDABDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDD4
3 3 CS = O 3 3 3 3
3 3(or unspecified)3 legal 3 legal 3 legal 3
3 3 WS = i 3 3 3 3
3initiator3(or unspecified)3 3 3 3
3proposal 3 3 3 3 3
3 CDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDD4
3 3 CS = k 3 3 3 3
3 3 WS = i 3 legal 3 legal 3 not allowed 3
3 3(or unspecified)3 3 3 3
@DDDDDDDDDADDDDDDDDDDDDDDDDADDDDDDDDDDDDDDDADDDDDDDDDDDDDDDDADDDDDDDDDDDDDDDDY
Legend:
o CS means CheckpointSize
o WS means WindowSize
o i, j, k, m, and n are integer values with the following
relations:
0 s m s k < n (values assigned to CS)
0 < j s i (values assigned to WS)
o For unspecified parameters, the default applies. In this
case,the numeric relations apply, that is, the default values
substitutefor the unspecified integer.
7.5.4.4 RTS Protocol Limitations
The RTS Protocol Limitations for this profile are listed in
table 7.13.
Table 7.13 RTS protocol elements
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3Element Class Restriction 3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3 3
3PConnect M 3
3 DataTransferSyntax M Value = 0. 3
3pUserData M 3
3 checkpointSize H 3
3 windowSize H 3
3 dialogueMode H 3
3 ConnectionData M 3
3 applicationProtocol G Value = 1. 3
3 H Value = 8883. 3
3 ConnectionData 3
3 open G 3
3 recover G 3
3 3
3 open 3
3 RTS user data G 3
3 3
3 recover 3
3 SessionConnectionIdentifier G 3
3 3
3RTS user data 3
3 mTAName G Maximum length 32 characters 3
3 graphic subset of IA5 only. 3
3 password G Maximum length 64 octets 3
3 graphic subset of IA5 only. 3
3 < null RTS User Data > G Generated if other validation 3
3 methods are used. 3
3 3
3SessionConnectionIdentifier 3
3 CallingSSUserReference M Maximum length 64 octets including 3
3 encoding = 62 octets of T.61. 3
3 CommonReference M 3
3 AdditionalReferenceInformation H Maximum length 4 octets including 3
3 encoding = 2 octets of T.61. 3
3 3
3PAccept G 3
3 DataTransferSyntax M Value = 0. 3
3 pUserData M 3
3 checkpointSize H 3
3 windowSize H 3
3 ConnectionData M 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
(Continued on next page.)
Table 7.13 RTS protocol elements, continued
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3Element Class Restriction 3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3 3
3PRefuse G 3
3 RefuseReason M 3
3 3
3SS User Data G See Note 3
3 (in S-TOKEN-PLEASE) 3
3 3
3AbortInformation G 3
3 (in S-U-ABORT) 3
3 AbortReason H 3
3 reflectedParameter X Restricted to 8 bits. 3
3 3
3 End of Definitions 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
Note: Generated if supplied by the RTS-user. The RTS use may specify
a priority in the TURN-PLEASE primitive, and if so, it is carried as
the SS-User-Data in S-TOKEN-PLEASE.
7.5.5 Use of Session Services
The session requirements and use of session are covered in
section 5 of this document.
7.5.6 Data Transfer Syntax
This section defines Presentation Transfer Syntax and notation
rules applicable to these agreements. Implementations must
conform EXACTLY as specified in X.409 with no further
restrictions. Appendix 7C defines rendition of IA5 Text and T61
characters.
7.6 PRMD to ADMD and ADMD to ADMD
7.6.1 Introduction
This section defines the implementation agreements that apply to
the interface between two management domains when at least one is
an ADMD. A message arriving at an ADMD has either no recipient
within that domain or one or more recipients within that domain.
In the former case, the ADMD serves as a relay between two or
more domains and the actions required of that ADMD are
independent of the nature (PRMD or ADMD) of the domains. In the
latter case, the ADMD is responsible for delivering messages to
the proper recipient(s) within its jurisdiction, and may also be
responsible for relaying the message.
Given the two roles for an ADMD, this section describes two
distinct sets of functional requirements for an ADMD. The first
is the relaying requirement that is needed to provide PRMD and
other ADMD interworking. The second is analogous to the PRMD's
support to its customers through the integrated UAs. These are
distinct functional differences. The services provided to the
UAs of an ADMD are independent of the requirement that an ADMD
provide a function for interworking with any type of Management
Domain (MD). Figure 7.5 illustrates the two roles played by an
ADMD.
This section is presented in the form of deviations from the
agreements applicable to PRMD-to-PRMD (section 7.5). Unless
explicitly noted in the remainder of this section, all of the
specifications for PRMD to PRMD apply to PRMD to ADMD and ADMD to
ADMD.
ZDDDDDDDDDDDDDDDDDDD? ZDDDDDDDDDDDDDDDDDDD?
3 PRMD or ADMD 3 3 ADMD 3
3 ZDDDDDDDDDD? <--3---------------P2-------------------3--> ZDDDDDDDDD? 3
3 3 IPM - UA 3 3 3 3IPM - UA 3 3
3 CDDDDDDDDDD4 <--3---------------P1-------------------3--> CDDDDDDDDD4 3
3 3 MTA 3 3 3 3 MTA 3 3
3 @DDDDDDDDDDY 3 3 @DDDDDDDDDY 3
@DDDDDDDDDDDDDDDDDDDY @DDDDDDDDDDDDDDDDDDDY
(a)
ZDDDDDDDDDDDDDDDDDDD? ZDDDDDDDDDDDDDDDDDDD?
3 PRMD or ADMD 3 3 PRMD or ADMD 3
3 ZDDDDDDDDDD? 3 3 ZDDDDDDDDDD? 3
3 3 IPM - UA 3 <--3---------------P2-------------------3-> 3 IPM - UA 3 3
3 CDDDDDDDDDD4 3 3 CDDDDDDDDDD4 3
3 3 MTA 3 3 3 3 MTA 3 3
3 @DDDDDDDDDDY 3 3 @DDDDDDDDDDY 3
@DDDDDDDDDDDDDDDDDDDY @DDDDDDDDDDDDDDDDDDDY
| |
| |
| |
P1 P1
| |
| ZDDDDDDDDDDDDDDDDDD? |
| 3 ADMD 3 |
---------------->3 ZDDDD? 3<------------------
3 3 MTA3 3
3 @DDDDY 3
@DDDDDDDDDDDDDDDDDDY
(b)
Figure 7.5 An ADMD may (b) or may not (a) serve as a relay
7.6.2 Additional ADMD Functionality
The following defines the additional ADMD specific functionality
required over and above that specified in the PRMD section.
7.6.2.1 Relay Responsibilities of an ADMD
ADMDs will relay all content types (not just P2) unchanged
in the absence of a request for conversion.
7.6.2.2 P1 Protocol Classification Changes
Table 7.14 describes the changes to the PRMD P1 Protocol
classifications required for a delivering Administration
domain (with respect to the original message; this means the
domain which originates the delivery reports).
Table 7.14 P1 Protocol Classification Changes for a Delivering ADMD
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 3
3 Protocol Elements Class 3
3 3
3 3
3 DeliveredInfo 3
3 typeOfUA H 3
3 3
3 ReportedRecipientInfo 3
3 SupplementaryInformation H See Note 1. 3
3 3
3 GlobalDomainIdentifier 3
3 PrivateDomainIdentifier H 3
3 3
3 3
3 3
3 3
3 For relaying Administration domains, the classifications are all "X"3
3 3
3 For originating Administration domains, these are all 3
3 "NOT APPLICABLE". 3
3 3
3 3
3 Note 1: Domains providing access to TELEX/TELETEX recipients, whether 3
3 directly or indirectly as a result of bilateral agreements 3
3 between domains, must ensure that this information, when 3
3 present, is accessible by the recipient of the delivery report. 3
3 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
7.6.2.3 O/R Names
O/R Names shall consist of:
o CountryName,
o AdministrationDomainName.
as well as one of the following:
o PrivateDomainName,
o PersonalName,
o OrganizationName,
o OrganizationalUnit,
o UniqueUAIdentifier,
o X121Address.
and permits the optional inclusion of a
o DomainDefinedAttributeList.
Note: The destination PrivateDomainName or OrganizationName
must be present if destined for a PRMD. The ADMD relaying
the message to that destination PRMD requires this element.
7.6.2.4 P1 ADMD Name
Management Domains (MDs) must specify in the ADMD name field
of the O/R Name StandardAttributeList in P1, the name of the
Administration domain:
o to which the message is being sent (in recipient names)
o from which the message originated (in the originator
name).
7.6.3 Interworking with Integrated UAs
If the message originates at a UA owned by an ADMD, or is
delivered to such a UA, the O/R Name follows the same Form 1
Variant 1 constraints as the base specifications; except that the
ADMD name is the name of the ADMD that owns the UA and instead of
supplying a PRMD Name, one (or more) of the following must be
provided:
o OrganizationName,
o OrganizationalUnit,
o PersonalName.
and may optionally include a
o DomainDefinedAttributeList.
7.6.4 Differences with Other Profiles
7.6.4.1 TTC Profile
There are no outstanding issues regarding interworking
between TTC-conformant systems and NBS-conformant systems
with the exception of the number of recipients and the
supported MPDU sizes. The ExtensionIdentifier field may
contain a maximum value of 32K-1; however, according to the
current TTC profile, if a message with more than 256
recipients is received, some TTC-conformant domain may
generate a nondelivery notification. This also applies to
the ReportedRecipientInfo in a delivery report. Further, a
TTC MTA is required to handle an MPDU size of at least 32KB.
The NBS required MPDU size is 2MB as covered in section
7.5.3.3. Other differences are shown in Appendix E. TTC is
currently based on Version 4 of the Implementor's Guide.
7.6.4.2 CEPT Profile
See Appendix 7E.
7.6.5 Connection of PRMDs to Multiple ADMDs
Given that Management Domain names (both PRMD and ADMD) shall be
unique within the U.S., then when an ADMD is presented a message
for transfer from a PRMD, it will accept O/R Names (both
originator and recipient) which have an AdministrationDomainName
field value different than the Administration's name. "Accept"
implies the attempt to route/deliver the message shall be made,
as appropriate, based upon the knowledge that MD names are
unique.
Whether this functionality is required by an Administration for
conformance to this agreement is for further study.
If a PRMD is connected to two or more ADMDs which are not
effectively connected (either directly or via a third ADMD), full
X.400 functionality shall not be available. Problems occur
especially in the areas of:
o Naming,
o Routing,
o Replying.
It should be noted that a single PRMD that is connected to more
than one ADMD can be represented by more than one combination of
country-name, ADMD-name, and PRMD name. For example, it may
occur that the PRMD-name for a particular PRMD may take different
values, depending on the ADMD-name. Implementors should be aware
of the consequences of these possibilities on routing.
7.6.6 Connection of an ADMD to a Routing PRMD
It is possible for a collection of interconnected private domains
to establish one domain as the "gateway" to an ADMD, and hence to
the world.
If an ADMD is connected to such a gateway PRMD, the individual
private domains shall be registered with the Administration.
Administrations need not support such connections.
Note also that upon receipt by the ADMD of a message originating
somewhere within the PRMD collection, that the TraceInformation
may contain more than one element.
The X.400 Recommendations specify that an ADMD should not attempt
to relay a message destined for another ADMD through a PRMD, thus
an ADMD should ensure that messages destined for another ADMD are
not relayed through a PRMD. It should be noted, however, that a
relaying PRMD will relay any such message it receives.
7.6.7 Management Domain Names
o All Management Domain Names (both Private and
Administration) shall be unique within the U.S.
o A central naming authority shall be established to register
domain names.
7.6.8 Envelope Validation Errors
For validation errors, a non-delivery notice shall be generated
(if possible) with reason code of 'unableToTransfer' and
diagnostic code of 'invalidParameters' (unless specified
otherwise).
ADMDs will validate P1 Envelopes in the following areas:
a) The X.409 syntax of all elements should be checked.
b) The pragmatic constraint limits (lengths of fields and
number of occurrences of fields) should be checked.
c) Semantic validation of the following elements should be
done:
o originator O/R Name,
o recipient O/R Name in the RecipientInfo,
o Priority.
d) Only recipient Names with the responsibility flag set should
be validated. The validation of O/R names is defined in
7.8.3.3; the validation of priority is defined in 7.8.3.7.1.
MPDU Identifier Validation
o Validation of the GlobalDomainIdentifier component of
the MPDU Identifier is performed upon reception of a
message (i.e., as a result of a TRANSFER.Indication).
o The country name should be known to the validating
domain, and depending on the country name, validation
of the ADMD name may also be possible.
o Additional validation of the GlobalDomainIdentifier is
performed against the corresponding first entry in the
TraceInformation. If inconsistencies are found during
the comparison, a non-delivery notice with the above
defined reason and diagnostic codes is generated.
o A request will be generated to the CCITT for a more
meaningful diagnostic code (such as
'InconsistentMPDUIdentifier').
7.6.9 Quality of Service
7.6.9.1 Domain Availability
7.6.9.1.1 ADMD Availability
The goal is to provide 24 hour per day availability.
Note that there will be periods of time when an ADMD
may be unavailable due to maintenance windows in its
supporting network or in an MTA within the domain.
7.6.9.1.2 PRMD Availability
Although the goal of PRMD availability is also 24 hours
per day, business reasons are likely to dictate some
different level of availability. ADMDs shall require a
profile from the PRMD that indicates its schedule of
regular availability to the ADMD.
7.6.9.2 Delivery Times
In the absence of standardized quality of service
parameters, the following are agreed to. When standardized
parameters from CCITT Study Group I become available, they
shall be adopted.
a) In table 7.15 the following delivery time targets are
established:
Table 7.15 Delivery Time Targets
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 Delivery Class 95% Delivered Before 3
3 3
3 Urgent 3/4 hour 3
3 Normal 4 hours 3
3 Non-Urgent 24 hours 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
b) The interval(s) between retries and the number of retry
attempts that an ADMD uses in attempting delivery to a
PRMD or integrated UA, will be locally determined
domain parameters. However, the total elapsed times
after which delivery attempts will be stopped are shown
in table 7.16. This implies that, after these times, a
Non-Delivery Notice will be generated.
An Administration shall continue to attempt delivery until
the forced nondelivery time, even if the recipient domain
has scheduled an unavailability window.
Table 7.16 Forced Nondelivery Times
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 Delivery Class NonDelivery Forced After 3
3 3
3 Urgent 4 hours 3
3 Normal 24 hours 3
3 Non-Urgent 36 hours 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
Note:Both tables apply to the period between acceptance by
the originating MTA in the originating Administration domain
to the time of delivery in the destination Administration
domain. Transit time within PRMDs is NOT included in the
above times.
7.6.10 Billing Information
a) All aspects relating to billing, charging, tariffs,
settlement, and in particular to the use of the
billingInformation field in the delivery report, is subject
to bilateral agreement, and shall not be addressed in these
implementation agreements.
b) No ADMD shall require a PRMD to supply or process billing
information.
7.6.11 Transparency
a) No P1 extensions, other than the MOTIS extensions are to be
allowed (Reference A/3211). Should an ADMD receive a
message containing P1 extensions, it shall generate a
non-delivery notice (if possible) with reason code of
unableToTransfer and diagnostic code of invalidParameters.
If MOTIS elements are present, a relaying MTA can optionally:
o Relay the message. If the MTA does relay, it must not
drop any of the protocol elements.
o Non-Deliver the message.
A receiving MTA can optionally:
o Deliver the message
o Non-Deliver the message.
b) The CCITT has been requested to establish a more meaningful
diagnostic code (such as protocolError) for this occurrence.
Such a code has now been provided in the Implementors Guide.
c) P2 extensions shall be relayed transparently by ADMDs.
7.6.12 RTS Password Management
RTS password management shall be a local matter. This includes:
o password length
o frequency of changes
o exchange of passwords with communicating partners
o loading passwords ( i.e., the timing of password
changes with respect to active associations).
7.6.13 For Further Study
Issues requiring further study are:
o Intra-Domain Routing
o Multi-Vendor Domains
7.7 INTER and INTRA PRMD CONNECTIONS
7.7.1 Introduction
This section is limited in scope to issues arising from the
indirect connection of a PRMD to another PRMD or to an ADMD, and
to the interconnection of MTAs to form inter-PRMD connections.
Indirect means that the connection is made via a relaying PRMD.
The X.400 Recommendations describe the way that a PRMD connects
to a ADMD and the way that an ADMD connects to another ADMD. The
Recommendations do not, however, describe the way that a PRMD
connects indirectly to an ADMD or another PRMD, nor do they
describe the way that MTAs are connected within a PRMD. These
configurations (shown in Figures 7.6 and 7.7) are useful, for
example, in connecting equipment from different vendors at a
single customer site.
The P1 protocol and its related services for both inter and intra
PRMD connections are addressed in this section. In addition, a
method for routing within a PRMD is given. It is recognized that
uniform methods for Administration, maintenance, and quality of
service should be developed for such configurations, and this
work is for further study.
This section describes the minimum that must be provided in order
to implement a relaying PRMD and a MTA within a PRMD.
This section is presented in the form of deviations from
agreements applicable to PRMD to PRMD connection (section 7.5).
That is, unless specifically noted in the remainder of this
section, the agreements in section 7.5 apply to both relaying
PRMDs and MTAs within a PRMD.
It should be noted that the comments regarding ORNames in Section
7.6.5 also apply to this section.
7.7.2 The Relaying PRMD
A PRMD that has the capability of relaying messages to another
PRMD is called a relaying PRMD. A PRMD implementation need not
claim to be a relaying PRMD. A PRMD implementation which does
claim to be a relaying PRMD must follow the implementation
agreements in this section.
7.7.2.1 Relay Responsibilities of a PRMD
The responsibilities of a relaying PRMD are the same as
those of an ADMD (as specified in sections 7.6.8 and
7.6.2.1). In addition, the PRMD will simply deliver
messages routed to it from an ADMD, even if this results in
routing a message from the ADMD to the PRMD to another ADMD.
7.7.2.2 Interaction with an ADMD
In order for an ADMD to route a message to ADMD A via ADMD
B, it must know that A is reachable through B. Similarly,
in order for any MD to route a message to PRMD A via a
relaying PRMD B, it must know that A is reachable through B
(see Figure 7.8).
ZDDDDDDDD?
3 ADMD 3
@DDDBDDDDY
ZDDDDDDDD? ZDDDADDDD? ZDDDDDDDD?
3 PRMD A CDDDDDDDDDDD4 PRMD B CDDDDDDDDDDDD4 PRMD C 3
@DDDDDDDDY @DDDDDDDDY @DDDDDDDDY
Relay
Figure 7.6 Relaying PRMD
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 PRMD 3
3 ZDDDDDD? ZDDDDDD? 3
3 3MTA A 3 3 MTA D3 3
3 @DDBDDDY @DDBDDDY 3
3 3 3 3 ZDDDDDDD?
3 3 3 3 3 ADMD 3
3 ZDDADDD? ZDDADDD? 3 3 3
3 3MTA B CDDDDDDDDDDDDDDD4 MTA CCDDDEDDD4 or 3
3 @DDDDDDY @DDDDDDY 3 3 3
3 3 3 PRMD 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY @DDDDDDDY
Figure 7.7 Intra PRMD connections
Note 1: Section 7.6.6 specifies that ADMDs are not required to
connect to a relaying PRMD, but they are not precluded from doing
so.
Note 2: TraceInformation may have more than one sequence on
submission of a message by a relaying PRMD to an ADMD.
ZDDDDDDD?
3 MD D 3
@DDDBDDDY
ZDDDDDADDDDDDDDD?
3 relay 3 ZDDDDDDDDDD? ZDDDDDDDD?
3 MD C with 3DDDDDDD4 relay CDDDDDDDD4 MD A 3
3 a message 3 3 MD B 3 @DDDDDDDDY
3 for A 3 @DDDDDDDDDDY
@DDDDDDDDDDDDDDDY
Figure 7.8 MD C must know of A to route the message
7.7.3 Intra PRMD Connections
A PRMD is composed of MTAs which cooperate to perform the
functions expected of a domain. An MTA implementation need not
claim to follow the implementation agreements of this section.
7.7.3.1 Relay Responsibilities of an MTA
The relaying responsibilities of an MTA are the same as
those of an ADMD (as specified in sections 7.6.8 and
7.6.2.1) with one exception: loop suppression within the
domain is done using the MOTIS InternalTraceInfo protocol
element. The MTA must validate the InternalTraceInfo (see
section 7.8.3.5 for details on validation). In addition,
the PRMD will simply deliver messages routed to it from an
ADMD, even if this results in routing a message from the
ADMD to the PRMD to another ADMD (please see section 7.6.6).
7.7.3.2 Loop Suppression within a PRMD
a) The only mechanism defined in the X.400 Recommendations
for suppressing loops is TraceInformation, which is
added on a per domain basis to detect and suppress
loops among domains. Loops among MTAs within a domain
need to be detected and suppressed. This implies that
each MTA must add trace information that is meaningful
within the domain. The MOTIS solution of adding
InternalTraceInfo to the P1 Envelope of a message was
adopted. The definition of InternalTraceInfo is given
in figure 7.9. The InternalTraceInfo is added by each
MTA within a PRMD to handle a message, and it is
examined in the same way as TraceInformation to detect
and suppress loops.
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 InternalTraceInfo ::= [APPLICATION 30] 3
3 IMPLICIT SEQUENCE OF 3
3 SEQUENCE { 3
3 MTAName, 3
3 MTASuppliedInfo } 3
3 3
3 MTAName ::= PrintableString 3
3 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
Figure 7.9 Definition of InternalTraceInfo
If the MTAName and password of X.411 are used for
validation, then it is recommended that the MTAName
used for validation also be used in the
InternalTraceInfo. However, there is a complication:
in X.411, MTAName is an IA5String, and the MTAname
defined by MOTIS is a PrintableString. Efforts will be
made to change the MOTIS definition from
PrintableString to IA5String.
b) Three actions are defined in MTASuppliedInfo: relayed,
rerouted, and recipientReassignment as shown in figure
7.10. The recipientReassignment action is not
supported in these agreements. The ability to generate
it is not required, and if it is present on an incoming
message, the action field will be ignored.
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 MTASuppliedInfo ::= SET { 3
3 arrival [0] IMPLICIT Time, 3
3 deferred [1] IMPLICIT Time OPTIONAL, 3
3 action [2] IMPLICIT INTEGER 3
3 { relayed(0), rerouted(1), recipientReassignment(2) } 3
3 previous MTAName OPTIONAL } 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
Figure 7.10 Defined Actions in MTASuppliedInfo
7.7.3.3 Routing Within a PRMD
a) Routing within a PRMD is complicated by the lack of a
directory standard. In particular, it constrains
intra-domain routing decisions to be based on some
combination of the intra-domain attributes of the O/R
Name, Organization Name Organizational Units, and
Personal Name. In order to enhance interworking and to
reduce the difficulty of configuring intra-domain
connections, it is useful to restrict the ways in which
these may be used in making routing decisions.
b) However, it is recognized that vendors may wish to
provide MTAs with varying degrees of routing capability
within a PRMD as a temporary expedient until
appropriate standards for automated construction of
directories and routing tables are available. This
section assigns class numbers to certain levels of
routing capability and discusses the consequences of
using MTAs which fall into each class. The
classification scheme will allow some diversity in
allocating O/R Name space and in configuring
intra-domain routes.
c) When other methods are recommended by standards bodies,
the classification scheme described here will become
obsolete. Large-scale, multi-vendor PRMDs may not be
practical in the absence of standardized methods.
7.7.3.3.1 Class Designations
When it is clear that a message is to be delivered
within a domain, the Country Name, ADMD Name, and PRMD
Name have already served their purpose in determining
the next MTA in the route to the recipient. The
remaining fields that might be used on making routing
decisions within the PRMD are the Organization Name,
Organizational Units, and Personal Name.
MTAs are classified by their ability to discriminate
between O/R names when making routing decisions within
a PRMD. Conformant MTAs will be classified as shown in
table 7.17.
Table 7.17 Conformant MTA Classifications
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 Class 1 Class 2 Class 3 3
3 3
3 Organization Name H H H 3
3 SEQUENCE OF Organizational Unit X H H 3
3 Personal Name X X H 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
a) An 'H' means that the MTA must be able to base its
intra-domain routing decisions on the given
component of the O/R Name. In particular, both
Class 2 and Class 3 MTAs must be able to
discriminate on all the members in a supplied
sequence of OrganizationalUnits. A Class 3 MTA
must be able to discriminate on all of the
elements in a PersonalName.
An 'X' means that the MTA need not have the
ability to discriminate on the given component.
b) There is a hierarchy in support of components.
The ability to discriminate on a given component
does not imply the requirement to do so: e.g., a
Class 3 MTA is not required to have tables for
every PersonalName in the domain. Equally, an MTA
which can discriminate on OrganizationalUnits to
make routing decisions need not always use the
full sequence in an O/R Name if a partial sequence
provides enough information.
c) The above classifications only apply to routing
decisions in selecting a next hop within a domain.
All MTAs are entitled to examine the full O/R Name
when identifying their own directly served UAs.
d) The routing table of a Class 1 MTA will be
relatively small, because intra-domain routing
decisions are based solely on OrganizationName.
The routing table of a Class 2 MTA may be
substantially larger and more complex because of
its ability to discriminate on OrganizationalUnits
as well as OrganizationName to make routing
decisions. The routing table of a Class 3 MTA may
be larger still, because its use of the components
of PersonalName in addition to the other
information.
7.7.3.3.2 Specification of MTA Classes
If an MTA implementation claims to follow the
implementation agreements, it must be either a Class 1,
Class 2, or a Class 3 MTA. The class of an MTA
implementation should be specified so that PRMD
administrators can choose equipment properly.
7.7.3.3.3 Consequences of Using Certain Classes of MTAs
Definition: An MTA which accepts submission requests
and furnishes delivery indications to a
UA is said to "directly serve" the UA.
a) The presence in a domain of an MTA acting as a
Class 1 or Class 2 MTA imposes administrative
restrictions on the assignment of O/R Names to UAs
and in the configuration of routes within that
domain.
o A Class 1 MTA may directly serve UAs from
several OrganizationNames. However, if a
Class 1 MTA directly serves a UA with a given
OrganizationName, no other MTA in the domain
may directly serve a user with the same
OrganizationName. This means that if all
MTAs in a domain are Class 1, then all UAs
with a given OrganizationName must be
assigned to the same MTA.
o A Class 2 MTA may directly serve UAs from any
combination of OrganizationName and sequence
of OrganizationalUnits. However, if a Class
2 MTA directly serves a UA with a given
combination, no other MTA in the domain may
directly serve a user with the same
combination. This means that if all MTAs in
a domain are Class 2, then all UAs with a
given OrganizationName and sequence of
OrganizationalUnits must be assigned to the
same MTA.
o A domain consisting entirely of Class 3 MTAs
is free of all the above restrictions.
b) If Class 1 or Class 2 MTAs are used to perform
relaying within a PRMD containing MTAs of other
classes, care must be exercised in determining the
topology of the domain to avoid leaving certain
UAs inacessible from certain MTAs within the
domain. The example below shows one of the
configurations that should be avoided. The
example is intended to stimulate careful
examination of the relationship between network
and organizational topologies.
ZDDDDDDDDDDDDDDD? ZDDDDDDDDDD? ZDDDDDDDDDDDDDDD?
3 MTA A 3 3 MTA B 3 3 MTA C 3
3 serving CDD ... DD4 CDD ... DD4 serving 3
3Organization X 3 3 (Class 1)3 3Organization X 3
@DDDDDDDDDDDDDDDY @DDDDDDDDDDY @DDDDDDDDDDDDDDDY
Figure 7.11 Example of a confirguration to be avoided
In Figure 7.11, B will route all messages for
Organization X to either A or C because B is a Class 1
MTA. The administrator who created this configuration
probably wanted B to route some messages for
Organization X to A, and some to C. However, B does
not have the capability for this because it is only a
Class 1 MTA. The configuration in Figure 7.11 can be
corrected by replacing B with a Class 2 or Class 3 MTA.
7.7.3.4 Uniqueness of MPDUidentifiers Within a PRMD
When generating an IA5String in an MPDUIdentifier, each MTA
in a domain must ensure that the string is unique within the
domain. This shall be done by providing an MTA designator
with a length of 12 octets which is unique within the
domain, to be concatenated to a per message string with
maximum length of 20 octets.
Two pieces of information, the MTA name and MTA designator,
need to be registered within a PRMD to guarantee uniqueness.
This registration facility need not be automated. If the
MTA name is less than or equal to 12 characters, it is
recommended that it also be used as the MTA designator.
7.7.4 Service Elements and Optional User Facilities
A PRMD made up of MTAs which support varying sets of service
elements in addition to those required in these agreements may
appear to provide inconsistent service for these elements. For
example, if one MTA supports deferred delivery and another MTA
does not, then deferred delivery can be used by some, but not
all, users in the PRMD. Similarly, if one MTA supports return of
contents and another does not, then a user outside of the PRMD
will receive returned contents for messages sent to one user, but
not for messages sent to another user. Note that this same
inconsistency occurs when sending to two PRMDs which support
different additional optional elements.
7.7.5 X.400 Protocol Definitions
This section describes additions and modifications to section
7.5.3 which are required for implementation of a relaying PRMD or
an MTA within a PRMD.
7.7.5.1 Protocol Classification
a) The classification scheme given in section 7.5.3.1
applies to elements passing from one PRMD to another.
For both relaying PRMDs, and MTAs in a PRMD, the same
classification scheme will be used, but within a PRMD
the classification applies to elements passing from one
MTA to another.
b) In addition to the classifications given in section
7.5.3.1, a classification of Prohibited has been used.
PROHIBITED = P
This element shall not be used. Presence of this
element is a protocol violation.
7.7.5.2 P1 Protocol Elements
Table 7.18 contains protocol elements and their classes. An
* signifies that the classification of the protocol element
has not changed from Table 7.8.
Table 7.18 P1 Protocol Elements
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3Element Class Restrictions and Comments 3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3 3
3UMPDUEnvelope 3
3 MPDUIdentifier M* This field needs to be unique 3
3 within a PRMD. See sections 3
3 7.7.3.4 for the method of 3
3 ensuring uniqueness. 3
3 3
3 originator M* It is recommended that all 3
3 components of the originator's 3
3 ORName be included to help ensure 3
3 that reports can be returned. 3
3 3
3 TraceInformation M* The first MTA in the domain to 3
3 receive the message adds the 3
3 TraceInformation. Subsequent 3
3 MTAs can update the 3
3 TraceInformation in the event of 3
3 conversion or deferred delivery. 3
3 When a message is generated, the 3
3 originating MTA adds the 3
3 TraceInformation. 3
3 3
3 InternalTraceInfo M/P This element is mandatory for 3
3 envelopes transferred between 3
3 MTAs within a PRMD, and 3
3 prohibited in messages 3
3 transferred outside the domain. 3
3 Elements are always added to the 3
3 end of the sequence. (See Note 1)3
3 3
3InternalTraceInfo M MTANames within a PRMD must be 3
3 MTAName unique. See section 7.7.3.4 for 3
3 the method of assuring uniqueness 3
3 Maximum length = 32 characters. 3
3 3
3 MTASuppliedInfo M 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
(Continued on next page.)
Table 7.18 P1 Protocol Elements, continued
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3Element Class Restrictions and Comments 3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3 3
3 3
3MTASuppliedInfo 3
3 arrival M 3
3 deferred X This field must be generated by 3
3 MTAs which perform deferred 3
3 delivery. 3
3 3
3 action M See section 7.7.3.2 for 3
3 restrictions on values of this 3
3 field. 3
3 3
3 previous X This field must be generated by 3
3 MTAs which perform rerouting. 3
3 3
3DeliveryReportEnvelope 3
3 TraceInformation M* The first MTA in the domain to 3
3 receive the report adds the 3
3 TraceInformation. When a report 3
3 is generated, the originating MTA 3
3 adds the TraceInformation. 3
3 3
3 InternalTraceInfo M/P This field is mandatory for 3
3 envelopes transferred between 3
3 MTAs within a PRMD, and 3
3 prohibited in messages 3
3 transferred outside the domain. 3
3 (See Note 1) 3
3DeliveryReportContent 3
3 intermediate InternalTraceInfo P If it were possible to include 3
3 this field in the delivery report 3
3 content, an audit and confirmed 3
3 report could be provided to 3
3 detect problems within a PRMD. 3
3 Efforts are being made to add 3
3 this field to the MOTIS 3
3 definition. 3
3 3
3DeliveredInfo 3
3 typeOFUA R* It is the responsibility of the 3
3 MTA generating the report to 3
3 generate this element. 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
(Continued on next page.)
Table 7.18 P1 Protocol Elements, continued
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3Element Class Restrictions and Comments 3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3 3
3ProbeEnvelope 3
3 TraceInformation M* The first MTA in the domain to 3
3 receive the probe adds the 3
3 TraceInformation. When a probe 3
3 is generated, the originating MTA 3
3 adds the TraceInformation. 3
3 3
3 InternalTraceInfo M/P This field is mandatory for 3
3 envelopes transferred between 3
3 MTAs within a PRMD, and 3
3 prohibited in messages 3
3 transferred outside the domain. 3
3 (See Note 1) 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
Note 1: The M classification is only applicable if an
implementation is claiming conformance according to section
7.10.2, point (g) 4th bullet.
7.7.5.3 Reliable Transfer Server (RTS)
In the pUserData of PConnect, the value of
applicationProtocol should be 1. This value was chosen
because the agreements on intra-domain connections are not
strictly P1, nor are they MOTIS. Philosophically, it would
be good to choose a new application protocol identifier for
these agreements, but this introduces too many practical
problems. Since these agreements are closer to P1 than to
MOTIS, the value of 1 will be used. This will not cause
interworking problems between domains, because the only
deviation from P1 is the InternalTraceInfo, which will not
be present in messages transferred outside of a domain.
7.8 ERROR HANDLING
This section describes appropriate actions to be taken upon receipt of
protocol elements which are not supported in this profile, malformed
MPDUs, unrecognized O/R Name forms, content errors, errors in
reports, and unexpected values for protocol elements.
7.8.1 MPDU Encoding
The MPDU should have a context-specific tag of 0, 1, or 2. If it
does not have one of these tags, it is not possible to figure out
who originated the message. Therefore, the way this error is
reported is a local matter.
7.8.2 Contents
Once delivery to the UA has occurred, it is not possible to
report errors in P2 information to the originator. In addition,
it seems unreasonable to insist that the MTA that delivers a
message ensure that the P2 content of the message is acceptable.
As a result, the handling of content errors is a local matter.
7.8.3 Envelope
This section describes the handling of errors in message
envelopes. Some of the error conditions described below may be
detected in a recipient's O/R Name. This may limit the reporting
MTA's ability to generate a nondelivery notification that
accurately reflects the erroneous O/R Name in the
ReportedRecipientInfo. This handling of this situation is a
local matter.
7.8.3.1 Pragmatic Constraint Violations
In all cases of pragmatic constraint violation, a
nondelivery report should be generated with a ReasonCode of
unableToTransfer, and a DiagnosticCode of
pragmaticConstraintViolation.
7.8.3.2 Protocol Violations
a) If all required protocol elements are not present, a
nondelivery report with a ReasonCode of
unableToTransfer and a DiagnosticCode of
protocolViolation should be generated.
b) If a protocol element is expected to be of one type,
but is encoded as another, then a nondelivery report
with a ReasonCode of unableToTransfer and a
DiagnosticCode of invalidParameters should be
generated.
7.8.3.3 O/R Names
a) The domain that has responsibility for delivering a
message should also have the responsibility to send the
nondelivery notification if the message cannot be
delivered. Therefore, each MTA should only validate
the O/R Names of recipients with responsibility flags
set to TRUE. In addition, a nondelivery notification
can only be sent if the originator's O/R Name is valid.
b) If any element in the O/R Name is unrecognized or if
the CountryName, AdministrationDomainName, and one of
PrivateDomainName and OrganizationName (and, for ADMDs,
PersonalName and OrganizationalUnit) are not all
present, then a nondelivery report should be generated
with a ReasonCode of unableToTransfer, and a
DiagnosticCode of unrecognizedORName. If the message
can be delivered even though the ORName is invalid,
delivery is a local matter. Note, however, that if the
message is delivered, the invalid ORName might be
propagated through the X.400 system (e.g., by
forwarding).
c) If the O/R Name has all of the appropriate protocol
elements and the message still cannot be delivered to
the recipient, the following DiagnosticCodes may appear
in the nondelivery report: unrecognizedORName,
ambiguousORName, and uaUnavailable.
7.8.3.4 TraceInformation
a) Since non-relaying domains need not do loop
suppression, domains with responsibility for delivering
the message need not be concerned about the semantics
of the TraceInformation, that is, arrival time and
converted EncodedInformationTypes can be provided to
the UA without inspection by the MTAs of the domain as
long as the TraceInformation is properly encoded
according to X.409.
b) When a message is accepted for relay, the relaying
domain must check that a TraceInformation SEQUENCE has
been added by the domain that last handled the message.
If the appropriate TraceInformation was not added, this
should be treated as a protocolViolation (section
7.8.3.2).
c) In addition, the relaying domain must check that the
information was added in the sequence defined by the
rules for adding TraceInformation in the CCITT X.400
Implementor's Guide. If the sequence is invalid,then a
nondelivery report should be generated with a
ReasonCode of unableToTransfer and a diagnosticCode of
invalidParameters.
Note: It would be desirable for the CCITT to add a
diagnostic code of invalidTraceInformation to allow a more
meaningful description of this problem. A request for this
new diagnostic code will be submitted.
7.8.3.5 InternalTraceInfo
This section applies only to MTAs which follow the
agreements of section 7.7.
a) When a message is accepted for relay from another MTA
in the domain, the relaying MTA must check that an
InternalTraceInfo SEQUENCE has been added by the MTA
that last handled the message. If the appropriate
InternalTraceInfo was not added, this should be treated
as a protocolViolation (section 7.8.3.2).
b) In addition, the relaying MTA must check that the
information was added in the sequence defined by the
rules for adding TraceInformation in the CCITT X.400
Implementor's Guide. If the sequence is invalid, then
a nondelivery report should be generated with a
ReasonCode of unableToTransfer and a diagnosticCode of
invalidParameters.
Note:It would be desirable for the CCITT to add a diagnostic
code of invalidTraceInformation to allow for a more
meaningful description of this problem. A request for this
new diagnostic code will be submitted.
7.8.3.6 Unsupported X.400 Protocol Elements
The protocol elements defined in X.400 but unsupported by
this profile are: the deferredDelivery and
PerDomainBilateralInfo parameters of the UMPDUEnvelope, the
ExplicitConversion parameter of RecipientInfo, and the
alternateRecipientAllowed and contentReturnRequest bits of
the PerMessageFlag. Appropriate actions are described below
for domains that do not support the protocol elements.
7.8.3.6.1 deferredDelivery
The delivering domain shall do one of the following:
o deliver at once,
o hold for deferred delivery,
o return a nondelivery notification with a
ReasonCode of unableToTransfer and a
DiagnosticCode of noBilateralAgreement.
7.8.3.6.2 PerDomainBilateralInfo
If a delivering domain receives this element, the
element can be ignored.
7.8.3.6.3 ExplicitConversion
If ExplicitConversion is requested the message should
be delivered if possible. That is, if the UA is
registered to accept the EncodedInformationTypes of the
message, then the message should be delivered even
though the requested conversion could not be performed
along the route. If delivery is not possible, then a
nondelivery report should be generated with a
ReasonCode of conversionNotPerformed with no
DiagnosticCode.
7.8.3.6.4 alternateRecipientAllowed
If a delivering domain receives this element the
element can be ignored.
7.8.3.6.5 contentReturnRequest
If a delivering domain receives this element, the
element can be ignored.
7.8.3.7 Unexpected Values for INTEGER Protocol Elements
There are three INTEGERs in the P1 Envelope. Appropriate
actions are described below for domains receiving unexpected
values for Priority, ExplicitConversion, and ContentType.
7.8.3.7.1 Priority
Additional values for Priority have been suggested by
at least one group of implementors as upward compatible
changes to the X.400 Recommendations. Therefore, if a
PRMD receives an unexpected value for Priority, and
this value is greater than one byte in length, a
nondelivery report should be generated with a
ReasonCode of unableToTransfer and DiagnosticCode of
invalidParameters. If the value is less than or equal
to one byte, the PRMD can either generate a nondelivery
report as previously specified or interpret the
Priority as normal and deliver or relay the message.
7.8.3.7.2 ExplicitConversion
When an unexpected value is received for
ExplicitConversion, it should be handled as in section
7.8.3.6.3.
7.8.3.7.3 ContentType
If the ContentType is not supported by the delivering
MTA, then a nondelivery report should be generated with
a ReasonCode of unableToTransfer, and a DiagnosticCode
of contentTypeNotSupported.
7.8.3.8 Additional Elements
In the absence of multilateral agreements to the contrary,
receipt of privately tagged elements and protocol elements
in addition to those defined in X.400 will result in a
nondelivery report with a ReasonCode of unableToTransfer and
a DiagnosticCode of invalidParameters.
The exceptions to this are the MOTIS elements. The
treatment of MPDU's containing these MOTIS extensions is
described in Section 7.6.11.
7.8.4 Reports
There is no mechanism for returning a delivery or status report
due to errors in the report itself. Therefore the handling of
errors in reports is a local matter.
7.9 MHS USE OF DIRECTORY SERVICES
7.9.1 Directory Service Elements
a) Recommendation X.400 recognizes the need of MHS users for a
number of directory service elements. Directory service
elements are intended to assist users and their UAs in
obtaining information to be used in submitting messages for
delivery by the MTS. The MTS may also use directory service
elements to obtain information to be used in routing
messages. Some functional requirements of directories have
been identified and are listed below.
o Verify the existence of an O/R name.
o Return the O/R address that corresponds to the O/R name
presented.
o Determine whether the O/R name presented denotes a user
or a distribution list.
o Return a list of the members of a distribution list.
o When given a partial name, return a list of O/R name
possibilities.
o Allow users to scan directory entries.
o Allow users to scan directory entries selectively.
o Return the capabilities of the entity referred to by
the O/R name.
o Provide maintenance functions to keep the directory
up-to-date.
b) In addition to functionality, a number of operational
aspects must be considered. These include
user-friendliness, flexibility, availability, expandability,
and reliability.
c) Currently, these aspects of directory service elements and
procedures are under study by both the CCITT and the ISO.
Both organizations are committed to the development of a
single Directory Service specification for use by MHS and
all other OSI based applications.
Given the incomplete nature of the ongoing activities within
the CCITT and the ISO, no implementation details will be
provided now for MHS use of Directory Services.
Implementation agreements for MHS Use of Directory Services
will be issued when current activities within the CCITT and
the ISO are stable.
7.9.2 Use of Names and Addresses
a) It is recognized that these agreements enable a wide variety
of naming and addressing attributes (see section 7.5.3.5
ORName Protocol Elements) wherein each PRMD may adopt
particular routing schemes within its domain.
b) With the exception of the intra-domain connection
agreements:
These agreements make no attempt to recommend a standard
practice for electronic mail addressing.
c) Inter-PRMD addressing may be secured according to practices
outside the scope of these agreements, such as:
o manual directories
o on-line directories
o ORName address specifications
o ORName address translation.
d) Further, each PRMD may adopt naming and addressing schemes
wherein the user view may take a form entirely different
from the attributes reflected in table 7.9. And, each PRMD
may have one user view for the originator form and another
for the recipient form, and perhaps other forms of user
addressing. In some cases (e.g., receipt notification)
these user forms must be preserved within the constraints of
these implementation agreements. However, mapping between
one PRMD user form to another PRMD user form, via the X.400
ORName attributes of these agreements, is outside the scope
of these agreements.
7.10 CONFORMANCE
7.10.1 Introduction
In order to ensure that products conform to these implementation
agreements, it is necessary to define the types and degrees of
conformance testing that products must pass before they may be
classified as conformant. This section defines the conformance
requirements and provides guidelines for the interpretation of
the results from this type of testing.
This section is incomplete and will be enhanced in future
versions of this Agreement. Later versions will reflect the
problems of conformance testing and will outline specific
practices and recommendations to aid the development of
conformance tests and procedures.
7.10.2 Definition of Conformance
For this section, the term conformance is defined by the
following:
a) The tests indicated for this section are intended to
establish a high degree of confidence in a statement that
the implementation under test (IUT) conforms (or does not
conform) to the agreements of this section.
b) Conformance to a service element means that the information
associated with the service element is made accessible to
the user (person or process) whenever this agreement says
that this information should be available.
Accessible means that information must be provided
describing how a user (person or process):
o causes appropriate information to be displayed, or
o causes appropriate information to be obtained.
c) Conformance to P1, P2, and RTS as part of an X.400 OSI
application requires that only the external behavior of that
OSI system adheres to the relevant protocol standards.
In order to achieve conformance to this section, it is not
required that the inter-layer interfaces be available for
testing purposes.
d) Conformance to the protocols requires:
o that MPDUs correspond to instances of syntactically
correct data units,
o MPDUs in which the data present in the fields and the
presence (or absence) of those fields is valid in type
and semantics as defined in X.400, as qualified by this
profile,
o correct sequences of protocol data units in responses
(resulting from protocol procedures).
e) Statements regarding the conformance of any one
implementation to this profile are not complete unless a
Protocol Implementation Conformance Statement (PICS) is
supplied.
f) The term "Implementation Under Test" (IUT) is
interchangeable with the term "system" in the definition of
conformance, and may refer to:
o a domain, which may be one or more MTA's with
co-located or remote UA's,
o a single instance of an MTA and co-located UA with
X.400 (P1, P2, RTS and session) software,
o a relaying product with P1, RTS and session software,
o a gateway product.
g) Claiming Implementation Conformance
o An implementation which claims to be conformant as an
ADMD must adhere to the agreements in sections 7.5 and
7.6.
o An implementation which claims to be conformant as a
PRMD must adhere to the agreements in section 7.5.
o An implementation which claims to be conformant as a
relaying PRMD must adhere to the agreements in section
7.5 and the appropriate sections of 7.7.
o An implementation which claims to be conformant to the
intra-domain connection agreements must adhere to the
agreements in section 7.5 and the appropriate sections
of 7.7.
7.10.3 Conformance Requirements
7.10.3.1 Introduction
Conformance to this specification requires that all the
services listed as supported in sections 7.5, 7.6, and if
appropriate, 7.7 of these agreements are supported in the
manner defined, in either the CCITT X.400 Recommendations or
these agreements. It is not necessary to implement the
recommended practices of section 7.12, Appendix B, in order
to conform to these agreements.
It is the intention to adopt, where and when appropriate the
testing methodology and/or the abstract test scenarios
currently being defined by the CCITT X.400 Conformance
Group. However, it is recognized that formal CCITT
Recommendations relating to X.400 Conformance Testing will
not be available until 1988. It is also recognized that
aspects of these agreements are outside the scope of the
CCITT, and that other organizations will have to provide
conformance tests in these cases.
7.10.3.2 Initial Conformance
This section is intended to provide guidelines to vendors
who envisage having X.400 products available prior to any
formal mechanism, or "Conformance Test Center" being made
accessible that would allow for conformance to this product
specification to be tested.
It is feasible that vendors and carriers will want to enter
bilateral test agreements that will allow for initial trials
to be carried out for the purposes of testing initial
interworking capabilities. It is equally feasible that for
the purposes of testing interoperability, only a subset of
this specification will initially be tested.
Note: By claiming conformance to this subset of information
the vendor or carrier CANNOT claim conformance to this
entire specification.
There are two aspects to the requirements, interworking and
service, as described in the following sections.
7.10.3.2.1 Interworking
The interworking requirements for conformance implies
that tests be done to check for the syntax and
semantics of protocol data elements for a system as
defined by the classification scheme of sections
7.5.2.1.1 and 7.7.5.2. For a relay system, the correct
protocol elements should be relayed as appropriate.
For a recipient system, a message with correct protocol
elements must not be rejected where appropriate.
7.10.3.2.2 Service
For information available to the recipients via the
IPMessage Heading and Body, the following should be
made accessible:
o IPMessage ID - only the PrintableString portion of
the IPMessageId needs to be accessible.
o subject,
o primaryRecipients,
o copyRecipients,
o blindcopyRecipients,
o authorizingUsers,
o originator,
o inReplyTo,
o replyToUsers,
o importance,
o sensitivity,
o IA5Text Bodypart.
7.11 APPENDIX A: INTERPRETATION OF X.400 SERVICE ELEMENTS
The work on service element definitions is limited to those that are
defined as 'supported' in section 7.5 of this specification. Furthermore
it is not the intent of this section to define how information should be
made available or presented to a MHS user, nor is it intended to define
how individual vendors should design their products. In addition,
statements on conformance to a specific service element and the
allocation of error codes that are generated as a result of violations of
the service should be defined in the sections on conformance and errors
as part of the main product specification. The main objective is to
provide clarification, where required, on the functions of a service
element, and in particular what the original intent of the
Recommendations were.
SERVICE ELEMENTS
The following Service Elements defined in X.400 have been examined and
require further text to be added to their definitions to represent the
proposed implementation of these service elements by the X.400 SIG.
The service element clarifications are to be taken in the context of this
profile.
Service elements not referenced in this section are as defined in X.400.
PROBE
A PRMD need not generate probes.
If a probe is addressed to and received by a PRMD, the PRMD must respond
with a Delivery Report as appropriate at the time the probe was
processed.
DEFERRED DELIVERY
In the absence of bilateral agreements to the contrary, Deferred Delivery
and Deferred Delivery Cancellation are local matters (i.e., confined to
the originating domain) and need not be provided.
The extension of Deferred Delivery beyond the boundaries of the
initiating domain is via bilateral agreement as specified in Section
3.4.2.1 of X.411.
Content Type Indication
It is required that both an originating and recipient domain be able to
support P2 content type. The ability for domains to be able to exchange
content types other than P2 will depend on the existence of bilateral or
multi-lateral agreements.
Original Encoded Information Types Indication
It is required that both an originating and recipient domain be able to
support IA5 text. Support for other encoded information types, for the
purposes of message transfer between domains, will depend on the
existence of bilateral or multi-lateral agreements.
The use of the 'unspecified' form of encoded information type should only
be used when the UMPDU content represents an SR-UAPDU or contains an
auto-forwarded IM-UAPDU.
The original encoded information type of a message is not meaningful
unless a message is converted en route to the recipient. These
agreements support only IA5 text, which should not undergo conversion.
The original encoded information types should be made accessible to the
recipient for upward compatibility with the use of non-IA5 text message
body parts.
Registered Encoded Information Types
A UMPDU with an 'unspecified' value for Original Encoded Information Type
shall be delivered to the UA.
Delivery Notification
The UAContentID may be used by the recipient of the delivery notification
for correlation purposes.
Disclosure of Other Recipients
This service is not made available by originating MTAE's to UAE's, but
must be supported by relaying and recipient MTAE's.
By supporting the disclosure of other recipients the message recipient
can be informed of the O/R names of the other recipient(s) of the
message, as defined in the P1 envelope, in addition to the O/R
Descriptors within the P2 header.
These agreements do not support initiation of disclosure of other
recipients, but the information associated with it should be made
accessible to the recipient for upward compatibility with support for the
initiation of this service element.
Typed Body
As defined in X.400 with the addition of the Private Body Types that are
to be supported. At present there is no mechanism provided within X.420
that would allow you to respond to reception of an unsupported body type.
Action taken in this situation is a local matter.
Blind Copy Recipient Indication
It should be considered that the recipient's UA acts on behalf of the
recipient, and therefore may choose to disclose all BCC recipients to
each other. Therefore it is the responsibility of the originating domain
to submit two or more messages, depending on whether or not each BCC
should be disclosed to each other BCC.
Auto Forwarded Indication
A UA may choose not to forward a message that was previously
auto-forwarded. In addition there is no requirement for an IPM UA that
does not support non-receipt or receipt notification to respond with a
non-receipt notification when a message is auto-forwarded.
Primary and Copy Recipients Indication
It is required that at least one primary recipient be specified; however,
for a forwarded message this need not be present. The recipient UA
should be prepared to accept no primary and copy recipients to enable
future interworking with Teletex, Fax, etc.
Sensitivity Indication
A message originator should make no assumptions as to the semantic
interpretation by the recipients UA regarding classifications of
sensitivity. For example, a personal message may be printed on a shared
printer.
Reply Request Indication
In requesting this service an originator may additionally supply a date
by which the reply should be sent and a list of the intended recipients
of the reply. If no such list is provided then the initiator of the reply
sends the reply to the originator of the message and any recipients the
reply initiator wishes to include. The replytoUsers and the replyBy date
may be specified without any explicit reply being requested. This may be
interpreted by the recipient as an implicit reply request. Note that for
an auto-forwarded message an explicit or implicit reply request may not
be meaningful.
Body Part Encryption
The original encoded information type indication includes the encoded
information type(s) of message body parts prior to encryption by the
originating domain. The ability for the recipient domain to decode an
encrypted body part is a local matter. Successful use of this facility
can only be guaranteed if there exists bilateral agreements to support
the exchange of encrypted body parts.
Forwarded IP message Indication
The following use of the original encoded information type in the context
of forwarded messages is clarified:
o If forwarding a private message body part the originator of the
forwarded message shall set the original encoded information
types in the P1 envelope to undefined for that body part.
o The encoded information types of the message being forwarded
should be reflected in the new original encoded information types
being generated.
o See Appendix 7B on recommended practices for the use of the
delivery information as part of Forwarded IP-message.
Multipart Body
It is the intent of multipart bodies to allow for the useful and
meaningful structuring of a message that is constructed using differing
body part types. For example, it is not recommended that a message made
up of only IA5 text should be represented as a number of IA5 body parts,
each one representing a paragraph of text.
7.12 APPENDIX B: RECOMMENDED X.400 PRACTICES
It is not necessary to follow the recommended practices when claiming
conformance to these agreements.
7.12.1 RECOMMENDED PRACTICES IN P2
1. ORDescriptor
Vendors following the NBS/OSI Workshop guidelines shall,
whenever possible, generate the ORName portion of an
ORDescriptor in ALL IPM heading fields.
2. ForwardedIPMessage BodyParts
ForwardedIPMessage BodyParts should be nested no deeper than
eight. There is no restriction on the number of
ForwardedIPMessage BodyParts at any given depth.
3. DeliveryInformation
It is strongly recommended that DeliveryInformation be
supplied in both forwarded and autoforwarded message body
parts. DeliveryInformation is useful when a message has
multiple forwarded message body parts because without it,
the EncodedInformationType(s) of the component forwarded
messages cannot be deduced easily. DeliveryInformation is
useful for autoforwarded messages because the
EncodedInformationType of an autoforwarded message is
"unspecified" and the EncodedInformationType(s) of the
message cannot be determined easily without it. Absence of
the EncodedInformationType(s) makes it difficult for a UA to
easily determine whether the message can be rendered.
7.12.2 RECOMMENDED PRACTICES IN RTS
1. In the case where S-U-ABORT indicates a temporaryProblem,
reestablishment of the session should not be attempted for a
"sensible" time period (typically not less than five
minutes).
In instances where this delay is not required or necessary,
report a localSystemProblem.
2. S-U-EXCEPTION-REPORT reason codes can be interpreted as
follows:
o receiving ability jeopardized (value 1)
Possible meaning: The receiving RTS knows of an
impending system shutdown.
o local ss-User error (value 5)
Possible meaning: The receiving RTS needs to
resynchronize the session dialogue.
o irrecoverable procedure error (value 6)
Possible meaning: The receiving RTS has had to delete
a partially received APDU, even though some minor
synchronization points have been confirmed.
o non specific error (value 0)
Possible meaning: The receiving RTS cannot handle the
APDU (for example, because it was too large) and wishes
to inform the sending RTS not to try again.
o sequence error (value 3):
Possible meaning: The S-ACTIVITY-RESUME request
specified a minor synchronization point serial number
which does not match the checkpoint data.
3. For purposes of identifying an MTA during an RTS Open, OSI
addressing information should be used. This addressing
information is conveyed by lower layer protocols and is
reflected by the calling and called SSAP parameters of the
S-CONNECT primitives.
MTA validation and identification are related, but separate,
functions. The mTAName and password protocol elements of
the RTS user data should be used for validation, rather that
identification, of an MTA. The RTS initiator and responder
may independently require each other to supply mTAName and
password.
The CallingSSUserReference parameter of the S-CONNECT
primitives should only have meaning to the entity that
encoded it and should not be used to identify an MTA.
7.12.3 RECOMMENDED PRACTICES FOR ORName
Table 7.9 stipulates that the StandardAttributeList must contain
either PrivateDomainName or OrganizationName. It is recommended
that, for both originator and recipients in a private domain, the
PrivateDomainName field be used.
It is recommended that there should be a DomainDefinedAttribute
to be used in addressing UAs in existing mail systems, in order
to curtail the proliferation of different types of
DomainDefinedAttributes used for the same purpose. The syntax of
this DomainDefinedAttribute conforms to the CCITT Pragmatic
Constraints, and thus has a maximum value length of 128 octets
and a type length of 8 octets, each of type Printable String.
Only one occurrence is allowed.
This DomainDefinedAttribute has the type name "ID" (in
uppercase). It contains the unique identifier of the UA used in
addressing within the domain. This DomainDefinedAttribute is to
be exclusively used for routing within the destination domain
(i.e., once routed to that domain via the mandatory components of
the StandardAttributeList); any other components of the
StandardAttributeList may be provided. If they conflict delivery
is not made.
The contents of this parameter need not be validated in the
originating domain or any relaying domain, but simply transferred
intact to the next MTA or domain.
Class 2 and class 3 MTAs in a PRMD should allow administrators to
decide the number of OrganizationalUnits that should appear in
user names, instead of imposing a software controlled limit which
is less than four. This is desirable because when two different
vendors impose different limits on the number of
OrganizationalUnits in a name, it becomes difficult for the
administrator to choose a sensible naming scheme.
There are existing mail systems that include a small set of non-
Printable String characters in their identifiers. For these
systems to communicate with X.400 messaging systems, either for
pass-through service or delivery to X.400 users, gateways will be
employed to encode these special characters into a sequence of
Printable String characters. This conversion should be
performed by the gateway according to a common scheme and before
insertion in the ID DDA, which is intended to carry electronic
mail identifiers. X.400 User Agents may also wish to perform
such conversions.
It is recommended that the following symmetrical encoding and
decoding algorithm for non-Printable String characters be
employed by gateways. The encoding algorithm maps an ID from an
ASCII representation to a PrintableString representation. Any
non-printable string characters not specified in the table are
covered by the category "other" in the table below.
The principal conversion table for the mapping is as follows:
Table 7B.1 Printable string to ASCII mapping
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 ASCII Character Printable String Character 3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3 % (percent) (p) 3
3 @ (at sign) (a) 3
3 ! (exclamation) (b) 3
3 " (quote mark) (q) 3
3 _ (underline) (u) 3
3 ( (left paren.) (l) 3
3 ) (right paren.) (r) 3
3 other (3DIGIT) 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
where 3DIGIT has the range 000 to 377 and is interpreted as the octal
encoding of an ASCII character.
To encode an ASCII representation to a PrintableString, the table and the
following algorithm should be used:
IF current character is in the encoding set THEN
encode the character according to the table above
ELSE
write the current character;
continue reading;
To decode a PrintableString representation to an ASCII representation,
the table and the following algorithm should be used:
IF current character is not "(" THEN
write character
ELSE
{
look ahead appropriate characters;
IF composite characters are in the above table THEN
decode per above table
ELSE
write current character;
}
continue reading;
Class 2 and class 3 MTAs in a PRMD should allow administrators to
decide the number of OrganizationalUnits that should appear in
user names, instead of imposing a software controlled limit which
is less than four. This is desirable because when two different
vendors impose different limits on the number of
OrganizationalUnits in a name, it becomes difficult for the
administrator to choose a sensible naming scheme.
7.12.4 POSTAL ADDRESSING
For domains wishing to support postal (or physical) delivery
options, the following interim set of "nationally-defined" domain
defined attributes are recommended. The CCITT will define
Standard Attributes in support of physical delivery in its 1988
Recommendations; this is only an interim solution.
CCITT will also be addressing the services associated with
physical delivery. This interim solution does not address the
end-to-end service aspects of physical delivery; in particular,
the following IPM service elements do not currently extend
outside of the X.400 environment:
o alternate Recipient Assignment
o PROBE
o Receipt Notification / Non-Receipt Notifications
o Grade of delivery
"Delivery" means passing a message from the MTS to the physical
delivery system (PDS), and not to the user (or user agent).
The following three DDAs are recommended to be used to specify a
postal (or physical) address:
CNTRPC - encodes the country and postal code for postal
delivery. The DDA value is of the form
"Country?Postalcode" (for example, "USA?22096"). The
country field is optional, the postal code is
optional; the separator ("?") is not. If both country
and postal code are missing, this DDA should not be
specified.
PDA 1 - The country and postal code fields are free-form text.
PDA 2 - These two DDA (signifying Postal Delivery Address
strings 1 and 2) form a 256 character free-form
postal address. Fields are separated by a question
mark ("?"). There is no implied separator between
PDA1 and PDA2. The meaning of the fields are defined
by each domain supporting the physical delivery
interface. PDA1 contains the first 128 characters,
PDA2 the next 128 characters. If the PDA string is
less than 128 characters, PDA2 is not used.
For example, if the domain interprets the PDA fields as lines,
the address
Mr. John Smith
Conway Steel
123 Main Street
Reston VA 22096
would be encoded as follows:
type = "PDA1" value = "Mr. John Smith?Conway Steel?123 Main
Street?Reston VA"
CNTRPC = "?22096"
7.12.5 EDI use of X.400
7.12.5.1 Introduction and Scope
This is a guideline for EDI data transfer in an X.400
environment conforming to the NBS agreements. These
recommended practices outline procedures for use in
transferring EDI transactions between trading partner
applications in an attempt to facilitate actual X.400
implementation by EDI users.
The scope of this guideline is to describe specific
recommendations for adopting X.400 as the data transfer
mechanism between EDI applications.
7.12.5.2 Model
The MHS recommendations can accommodate EDI through the
approach illustrated below. Many Message Transfer (MT)
service elements defined in the X.400 recommendations are
particularly useful to the EDI application.
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 X.400 Message (1 EDI interchange) 3
3 ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD? 3
3 3 3 3
3 3 ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD? 3 3
3 3 3 3 3 3
3 Envelope ------------------->3 P1 Control 3 3 3
3 3 3 Information 3 3 3
3 3 @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY 3 3
3 3 3 3
3 3 3 3
3 3 3 3
3 3 ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD? 3 3
3 3 3 One 3 3 3
3 Content ------------------->3 EDI 3 3 3
3 3 3 Interchange 3 3 3
3 3 @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY 3 3
3 3 3 3
3 @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY 3
3 MHS Message 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
This diagram depicts an EDI content (1 EDI interchange)
enveloped by the P1 MHS envelope. All the MT Services
defined in the X.400 Recommendations may be used for EDI.
However, it is not required to support optional or non-
essential services to exchange EDI data between EDI users.
When an EDI user submits an EDI Trade Document to the EDI
User Agent, the EDI UA will submit the EDI content plus P1
envelope to the Message Transfer System (MTS).
ZDDDDDDDDDDD? ZDDDDDDDDDDDD? ZDDDDDDDDDDD?
3 3 3 EDI 3 3 EDI 3
3 MTS 3<----------->3 UA 3<------------>3 User 3
3 3 3 3 3 3
@DDDDDDDDDDDY @DDDDDDDDDDDDY @DDDDDDDDDDDY
The EDI UA must support the essential MT Services as defined
in these Agreements; for example, as a minimum, to provide
default values for services not elected by the EDI user,
such as Grade of Delivery.
Note: MT Services are not necessarily made available by the
EDI UA to the EDI user.
7.12.5.3 Protocol Elements Supported for EDI
The following P1 protocol elements will be used to support
EDI applications:
Content Type
For EDI applications, the content type will be 0
(undefined content).
Original Encoded Information Types
Any EIT defined in the X.400 Recommendations may be
used to specify the encoding of EDI content. However,
for ANSI X12 EDI applications in particular, it is
expected that the "undefined" and "Ia5Text" EIT's will
normally be used, with "undefined" used to signify the
EBCDIC character set.
7.12.5.4 Addressing and Routing
It is anticipated that connection of some existing systems
to an X.400 service for EDI purposes will be by other than
X.400 protocols, at least in the short term.
EDI messages entering the X.400 environment will therefore
need to have X.400 O/R Names added to identify the
origination and recipient trading partners, typically by
means of local directory services in the origination domain
which will map EDI identifiers/addresses into O/R Names.
Such O/R Names will contain Standard Attributes as defined
in Table 7.9 and for recipient trading partners will at
least identify the destination domain.
In the case of trading partners outside the X.400
environment, it is expected, however, that there will be
cases where message delivery will require the provision of
addressing information beyond that which can be carried in
Standard Attributes. In such cases, Domain Defined
Attributes are recommended to be used.
The syntax of this DDA is as defined in Table 7.9, with a
single occurrence having the type name "EDI" (uppercase) and
a value containing the identifier/address of the trading
partner. For ASC X12 purposes, specifically, this value
will comprise the 2 digit interchange ID qualifier followed
by the interchange ID (max 15 characters). Routing on this
DDA shall only occur, if at all, in the destination domain.
7.12.6 USA Body Parts
It is recommended that UAs can generate any USA Body Part, as
defined in section 7.5.3.6.2, and that they can receive such body
parts as well. reception of USA Body Parts does not imply
further processing by the UA, but merely that the body part is
made available, with a indication of its registered body part
identifier, to another process or deposition in a file.
Generation implies the reverse of this process.
7.13 APPENDIX C: RENDITION OF IA5Text AND T61String CHARACTERS
7.13.1 GENERATING AND IMAGING IA5Text
The characters that may be used in an IA5String are the graphic
characters (including Space), control characters and Delete of
the IA5 character repertoire ISO 646.
The graphic characters that may be used with a guaranteed
rendition are those related with positions 2/0 to 2/2, 2/5 to
3/15, 4/1 to 5/10, 5/15 and 6/1 to 7/10 in the basic 7-bit code
table.
The other graphic characters may be used but have no guaranteed
rendition.
The control characters that may be used but have no guaranteed
effect are a subset consisting of the format effectors 0/10 (LF),
0/12 (FF) and 0/13 (CR) provided they are used in one of the
following combinations:
CR LF to start a new line
CR FF to start a new page (and line)
LF .. LF to show empty lines (always after one of the
preceding combinations).
The other control characters or the above control characters in
different combinations may be used but have no guaranteed effect.
The character Delete may occur but has no guaranteed effect. The
IA5String in a P2 IA5Text BodyPart represents a series of lines
which may be divided into pages. Each line should contain from 0
to 80 graphic characters for guaranteed rendition. Longer lines
may be arbitrarily broken for rendition. Note that X.408 states
that for conversion from IA5Text to Teletex, the maximum line
length is 77 characters.
7.13.2 GENERATING AND IMAGING T61String
For further study.
7.14 APPENDIX D: DIFFERENCES IN INTERPRETATION DISCOVERED THROUGH
TESTING OF THE MHS FOR THE CeBit 87 DEMONSTRATION
Several interworking problems were discovered through multi-vendor
testing. These problems, and recommendations for solutions to them are
discussed in this appendix.
7.14.1 ENCODING OF RTS USER DATA
The password is defined as an ANY in the X.400 Recommendations,
and implementor's groups have decided to use an IA5String for
this field. There was some confusion about what the X.409
encoding for this IA5String would be, and the correct encoding
is:
class: context specific
form: constructor
id code: 1
length: length of contents
contents: (primitive encoding)
IA5String: 16
length: length of contents
contents: the password string
class: context specific
form: constructor
id code: 1
length: length of contents
contents: (constructor encoding) left as an exercise for the
reader
Implementations should be prepared to receive any X.409 type for
the password because of its definition as an ANY.
7.14.2 EXTRA SESSION FUNCTIONAL UNITS
One vendor proposed more than the required set of functional
units on opening the session connection, and the receiver
rejected the connection. All debate aside about whether the
initiator should have proposed units outside of the required set,
or whether the receiver should have rejected the connection, the
set of functional units can be negotiated in a straightforward
way. The following is recommended.
If the initiator proposes using more than the required set of
functional units, the responder should specify the set of
functional units that it would like to use (which should include
the required set) in the open response. The session
implementations will automatically use the intersection of the
units proposed by both sides.
If the initiator proposes using less than the required set of
functional units, the responder should reject the connection.
Unfortunately, there is not an appropriate RefuseReason for
rejecting the connection, so instead of refusing the connection
in the response to the S-CONNECT, the receiver should issue an S-
U-ABORT with an AbortReason of protocolError. Note that it is
valid to issue an S-U-ABORT instead of responding to the S-
CONNECT. A problem report has been submitted to the CCITT
requesting the addition of a RefuseReason for this situation.
If the responder proposes using less than the required set of
functional units, the session connection is established before
the initiator can check for this. If too few functional units
have been proposed, the initiator should abort the connection
using S-U-ABORT, with an abort reason of protocolError.
7.14.3 MIXED CASE IN THE MTA NAME
The MTA name is frequently exchanged over the telephone when two
systems are being configured to communicate with one another. In
one such telephone exchange, the casing of the MTA name was not
specified, the MTA name consisted of both upper and lower case
letters, and one of the implementations compared MTA names for
equality in a case sensitive manner. Consequently, connections
failed until the problem was detected and repaired. It is
recommended that the MTA name be compared for equality in a case
insensitive manner, and that the password be compared for
equality in a case sensitive manner.
7.14.4 X.410 ACTIVITY IDENTIFIER
The X.400 Implementor's Guide recommends that the activity
identifier be X.409 encoded, but this is only a recommendation
and not a requirement. Consequently, receiving systems cannot
assume that the activity identifier will be X.409 encoded.
7.14.5 ENCODING OF PER RECIPIENT FLAG AND PER MESSAGE FLAG
In the definition of the PerRecipientFlag in X.411, there is a
statement that the last three bits are reserved, and should be
set to zero. It is unclear whether those bits are unused in the
X.409 encoding. Receivers should accept encodings with either
zero or three unused bits. A problem report has been submitted
to the CCITT asking for clarification.
Though there is not any statement in X.411 about the last four
bits of the PerMessageFlag, some vendors have encoded this with
zero unused bits, and some have encoded it with four unused bits.
The PerMessageFlag should be encoded with at least four unused
bits.
7.14.6 ENCODING OF EMPTY BITSTRINGS
There are three valid encodings for an empty bitstring: a
constructor of length zero, a constructor of indefinite length
followed by the end-of-contents terminator, and a primitive of
length one with a zero octet as the value.
7.14.7 ADDITIONAL OCTETS FOR BITSTRINGS
Nothing in X.409 constrains an implementation from sending two,
three, four, or even more octets for a bitstring that fits into
one octet, with the undefined bits set to zero. Note that the
number of excess octets is bounded by the pragmatic constraints
guidelines of the CCITT X.400 Implementor's Guide for all of the
bitstrings in P1.
7.14.8 APPLICATION PROTOCOL IDENTIFIER
If a value other that 1 is received in the applicationProtocol of
the pUserData in the PConnect, NBS implementations will reject
the connection. If CEN/CENELEC implementations receive a value
other than 8883 for this field, they will reject the connection.
This is an unfortunate state of affairs, because if NBS
implementations accept the value of 8883 without supporting the
MOTIS service elements, they would be misrepresenting themselves.
To make matters worse, CEPT uses a value of 1, but relays MOTIS
elements, which means that MOTIS elements will be relayed to
implementations using a value of 1 to demonstrate that they do
not support MOTIS. Work is continuing to try to find a solution
that will allow European implementations to interwork with U.S
implementations.
7.14.9 INITIAL SERIAL NUMBER IN S-CONNECT
This should be implemented in accordance with section 3.5.1 E4 of
the Implementors' Guide.
7.14.10 CONNECTION DATA ON RTS RECOVERY
It is clarified that the ConnectionData is identical in both the
S-CONNECT.request and the S-CONNECT.response. The value of the
ConnectionData is the old Session Connection Identifier.
7.14.11 ACTIVITY RESUME
If an activity is being resumed on a new session connection, it
is not clear from X.410 and X.225 whether all four of the called-
ss-user reference, the calling-ss-user reference, the common
reference, and the additional reference information should be
specified in the S-ACTIVITY-RESUME, or whether one of the ss-
user-references should be absent. It is also unclear whether the
called-ss-user reference should be identical to the calling-ss-
user reference if both are present. Consequently, receivers
should be tolerant of this situation. Appropriate problem
reports will be submitted to the CCITT asking for clarification.
7.14.12 OLD ACTIVITY IDENTIFIER
The Old Activity Identifier in S-ACTIVITY-RESUME refers to the
original activity identifier.
7.14.13 NEGOTIATION DOWN TO TRANSPORT CLASS 0
For European implementations, X.410 specifies that class 0
transport must be supported. However, it is permissible for an
initiator to propose a higher class as the preferred class,
provided that class 0 appears as the alternate class in the T-
Connect PDU. A responding implementation can choose to use
either the preferred or alternate class, but again, must be able
to use class 0. In other words, for private to private
connections in Europe, class 0 transport is required.
This conflicts with the NBS agreements, since class 0 is only
required if one of the partners in a connection is an ADMD.7.15APPENDIX E:WORLDWIDE X.400 CONFORMANCE PROFILE MATRIX
Y CONFORMANCE (E)
implies a conformance problem for European products in the U.S.
Y CONFORMANCE (US)
implies a conformance problem for U.S. products in Europe.
o The A/311 profile is specified in Env 41 202, the A/3211 profile
in Env 41 201
o No TTC protocol classification for RTS exists.
o The notation X/Y indicates "X" for PRMDs and "Y" for ADMDs, i.e.
"M/G" would be Mandatory for PRMDs and Generatable for ADMDs.
Table 7E.1 Protocol element comparison of RTS
ZDDDDDDDDDDDDDDDDDDDDDDDBDDDDDDDBDDDDDDDDDDBDDDDDDDDDBDDDDDDDDDDDDDDDDDDDDDDD?
3RTS element 3 NBS 3 A/311 3 A/3211 3 PROBLEM Y/N 3
CDDDDDDDDDDDDDDDDDDDDDDDEDDDDDDDEDDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDD4
3PConnect 3 M 3 M 3 M 3 N 3
3 DataTransferSyntax 3 M 0 3 M 0 3 M 0 3 N 3
3PUserData 3 M 3 M 3 M 3 N 3
3 checkpointSize 3 H 3 H 3 H 3 N 3
3 windowSize 3 H 3 H 3 H 3 N 3
3 dialogueMode 3 H 3 H 3 H 3 N 3
3 connectdata 3 M 3 M 3 M 3 N 3
3 applicationProtocol 3 G 1 3 H 1 3 R 8883 3 N 3
3 3 H 88833 3 3 3
3 ConnectionData 3 3 3 3 3
3 Open 3 G 3 G 3 G 3 N 3
3 Recover 3 G 3 H 3 G 3 N 3
3 3 3 3 3 3
3 Open 3 3 3 3 3
3 RTSUserData 3 G 3 G 3 G 3 N 3
3 3 3 3 3 3
3 Recover 3 3 3 3 3
3 SessionConnectionID 3 G 3 G 3 G 3 N 3
3 3 3 3 3 3
3RTSUserData 3 3 3 3 3
3 MTAName 3 G 3 G 3 G 3 N 3
3 3 3 3 3 3
3 Password 3 G 3 G 3 G 3 N 3
3 3 3 3 3 3
3 null 3 G 3 G 3 G 3 N 3
3 3 3 3 3 3
3SessionConnectionID 3 3 3 3 3
3 CallingUserReference 3 M 3 M 3 M 3 N 3
3 3 3 3 3 3
3 CommonReference 3 M 3 M 3 M 3 N 3
3 AdditionalRefInfo 3 H 3 H 3 H 3 N 3
3 3 3 3 3 3
3PAccept 3 G 3 G 3 G 3 N 3
3 DataTransferSyntax 3 M 0 3 M 0 3 M 0 3 N 3
@DDDDDDDDDDDDDDDDDDDDDDDADDDDDDDADDDDDDDDDDADDDDDDDDDADDDDDDDDDDDDDDDDDDDDDDDY
(Continued on next page.)
Table 7E.1 Protocol element comparison of RTS, continued
ZDDDDDDDDDDDDDDDDDDDDDDDBDDDDDDBDDDDDDDDDDDBDDDDDDDDDBDDDDDDDDDDDDDDDDDDDDDDD?
3RTS element 3 NBS 3 A/311 3 A/3211 3 PROBLEM (Y/N) 3
CDDDDDDDDDDDDDDDDDDDDDDDEDDDDDDEDDDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDD4
3 3 3 3 3 3
3PUserData 3 M 3 M 3 M 3 N 3
3 CheckpointSize 3 H 3 H 3 H 3 N 3
3 WindowSize 3 H 3 H 3 H 3 N 3
3 ConnectionData 3 M 3 M 3 M 3 N 3
3 3 3 3 3 3
3PRefuse 3 G 3 G 3 G 3 N 3
3 RefuseReason 3 M 3 M 3 M 3 N 3
3 3 3 3 3 3
3SSUserData 3 G 3 G 3 G 3 N 3
3 (in S-TOKEN-PLEASE) 3 3 3 3 3
3 3 3 3 3 3
3AbortInformation 3 G 3 G 3 G 3 N 3
3 (in S-U-ABORT) 3 3 3 3 3
3 AbortReason 3 H 3 H 3 H 3 N 3
3 reflectedParameter 3 X 3 X 3 X 3 N 3
@DDDDDDDDDDDDDDDDDDDDDDDADDDDDDADDDDDDDDDDDADDDDDDDDDADDDDDDDDDDDDDDDDDDDDDDDY
Table 7E.2 Protocol element comparison of P1
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDBDDDDDBDDDDDDDBDDDDDDBDDDDDDBDDDDDDDDDDDDDDDDDDDD?
3P1 Protocol 3 NBS 3 A/311 3A/32113 TTC 3 PROBLEM (Y/N) 3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEDDDDDEDDDDDDDEDDDDDDEDDDDDDEDDDDDDDDDDDDDDDDDDDD4
3 3 3 3 3 3 3
3 ORname 3 3 3 3 3 3
3 StandardAttributeList 3 M 3 M 3 M 3 M 3 N See Note 4 3
3 DomainDefAttributeList 3 X 3 X 3 X 3 G 3 Y See Note 5 3
3 3 3 3 3 3 3
3 StandardAttributeList 3 3 3 3 3 3
3 CountryName 3 R 3 R 3 R 3 M 3 N 3
3 3 3ISO R 3 R 3 3 N 3
3 3 3X.121 H3 H 3 3 Y Conformance (E) 3
3 3 3Other X3 X 3 3 Y Prot Vio 3
3 AdministrationDomainName 3 R 3 R 3 G 3 M 3 N 3
3 ... if PrintableString 3 3 R 3 G 3 3 N 3
3 ... if numericString 3 3 H 3 H 3 3 Y Conformance (E) 3
3 X.121 Address 3 X 3 X/R 3 X 3 3Y Conf(US)See Note 13
3 Terminal ID 3 X 3 X/G 3 X 3 3Y Conf(US)See Note 13
3 PrivateDomainName 3 G 3 G 3 G 3 G 3 N 3
3 3 3 3 3 3 3
3 OrganizationName 3 G 3 G 3 G 3 G 3 N 3
3 UniqueUAidentifier 3 X 3 X/G 3 X 3 3Y Conf(US)See Note 13
3 PersonalName 3 G 3 G 3 G 3 G 3 N 3
3 OrganizationalUnit 3 G 3 G 3 G 3 G 3 N 3
3 3 3 3 3 3 3
3 DomainDefinedAttribute 3 X 3 X 3 X 3 G 3 N 3
3 Type 3 M 3 M 3 M 3 M 3 N 3
3 Value 3 M 3 M 3 M 3 M 3 N 3
3 3 3 3 3 3 3
3 PersonalName 3 3 3 3 3 3
3 Surname 3 M 3 M 3 M 3 M 3 N 3
3 GivenName 3 G 3 G 3 G 3 G 3 N 3
3 Initials 3 G 3 G 3 G 3 G 3 N 3
3 3 3 3 3 3 3
3 GenerationQualifier 3 G 3 X 3 X 3 X 3 Y Conformance (E) 3
3 3 3 3 3 3 3
3 GlobalDomainIdentifier 3 3 3 3 3 3
3 CountryName 3 M 3 M 3 M 3 M 3 N 3
3 AdministrationDomainName 3 M 3 M 3 G 3 M 3 Y Proto Vio 3
3 PrivateDomainIdentifier 3 R/H 3 H 3 R 3 M/X 3 N 3
3 3 3 3 3 3 3
3 MPDU 3 3 3 3 3 3
3 UserMPDU 3 G 3 G 3 G 3 G 3 Y TTC required 3
3 3 3 3 3 3 MPDU size is 3
3 3 3 3 3 3 32K 3
3 DeliveryReportMPDU 3 G 3 G 3 G 3 G 3 N 3
3 3 3 3 3 3 3
3 ProbeMPDU 3 H 3 H 3 H 3 H 3 N 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDADDDDDADDDDDDDADDDDDDADDDDDDADDDDDDDDDDDDDDDDDDDDY
(Continued on next page.)
Table 7E.2 Protocol element comparison of P1, continued
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDBDDDDDBDDDDDDDBDDDDDDBDDDDDDBDDDDDDDDDDDDDDDDDDDD?
3P1 Protocol 3 NBS 3 A/311 3A/32113 TTC 3 PROBLEM (Y/N) 3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEDDDDDEDDDDDDDEDDDDDDEDDDDDDEDDDDDDDDDDDDDDDDDDDD4
3 3 3 3 3 3 3
3 UserMPDU 3 3 3 3 3 3
3 UMPDUenvelope 3 M 3 M 3 M 3 M 3 N 3
3 UMPDUcontent 3 M 3 M 3 M 3 M 3 N 3
3 3 3 3 3 3 3
3 UMPDUenvelope 3 3 3 3 3 3
3 MPDUidentifier 3 M 3 M 3 M 3 M 3 N 3
3 originatorORname 3 M 3 M 3 M 3 M 3 N 3
3 originalEncodedTypes 3 G 3 H 3 H 3 G 3 Y Conformance (E)3
3 3 3 3 3 3 3
3 ContentType 3 M 3 M 3 M 3 M 3 N 3
3 UAcontentID 3 H 3 H 3 H 3 H 3 N 3
3 Priority 3 G 3 G 3 G 3 G 3 N 3
3 PerMessageFlag 3 G 3 G 3 G 3 G 3 N 3
3 DeferredDelivery 3 X 3 X 3 X 3 X 3 N 3
3 PerDomainBilatInfo 3 X 3 X 3 X 3 X 3 N 3
3 RecipientInfo 3 M 3 M 3 M 3 M 3 Y TTC MPDU 32K 3
3 TraceInformation 3 M 3 M 3 M 3 M 3 N 3
3MOTIS-> LatestDelivery 3 3 3 X 3 3 N 3
3MOTIS-> InternalTraceInfo 3 M/P 3 3 P 3 3 N 3
3 UMPDUcontent 3 M 3 M 3 M 3 M 3 N 3
3 3 3 3 3 3 3
3 MPDUidentifier 3 3 3 3 3 3
3 GlobalDomainIdent 3 M 3 M 3 M 3 M 3 N 3
3 IA5string 3 M 3 M 3 M 3 M 3 N 3
3 3 3 3 3 3 3
3 PerMessageFlag 3 3 3 3 3 3
3 DiscloseRecipients 3 H 3G @ MTL3 H 3 H 3 Y Conformance (US)3
3 3 3H at UA3 ? 3 3 Y Conformance (US)3
3 ConversionProhibited 3 G 3 G 3 G 3 G 3 N 3
3 AlternatRecipAllowed 3 H 3G @ MTL3 H 3 X 3 Y Conformance (US)3
3 3 3H at UA3 ? 3 3 Y Conformance (US)3
3 ContentReturnRequest 3 X 3 X 3 X 3 X 3 3
3MOTIS-> redirectionProhibited 3 3 3 X 3 3 N 3
3 3 3 3 3 3 3
3 PerDomainBilateralInfo 3 3 3 3 3 3
3 CountryName 3 M 3 M 3 M 3 M 3 N 3
3 AdminDomainName 3 M 3 M 3 G 3 M 3 Y Prot Vio 3
3MOTIS-> PrivateDomainName 3 3 3 G 3 3 N 3
3 BilateralInfo 3 M 3 M 3 M 3 M 3 N 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDADDDDDADDDDDDDADDDDDDADDDDDDADDDDDDDDDDDDDDDDDDDDY
(Continued on next page.)
Table 7E.2 Protocol element comparison of P1, continued
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDBDDDDDBDDDDDDDBDDDDDDBDDDDDDBDDDDDDDDDDDDDDDDDDDD?
3P1 Protocol 3 NBS 3 A/311 3A/32113 TTC 3 PROBLEM (Y/N) 3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEDDDDDEDDDDDDDEDDDDDDEDDDDDDEDDDDDDDDDDDDDDDDDDDD4
3 DeliveryReportContent 3 3 3 3 3 3
3 original MPDUident 3 M 3 M 3 M 3 M 3 N 3
3 intermediate Trace 3 X/G 3 X 3 X 3 X 3 Y Conformance (E) 3
3 UAcontentID 3 G 3 G 3 G 3 G 3 N 3
3 ReportedRecipientInfo 3 M 3 M 3 M 3 M 3 Y TTC 256 max 3
3 returned 3 H 3 H 3 X 3 X 3 Y Conformance (E) 3
3 billing information 3 X 3 X 3 X 3 X 3 N 3
3 3 3 3 3 3 3
3 ReportedRecipientInfo 3 3 3 3 3 3
3 recipient ORname 3 M 3 M 3 M 3 M 3 N 3
3 extensionsIdentifier 3 M 3 M 3 M 3 M 3 N 3
3 PerRecipientFlag 3 M 3 M 3 M 3 M 3 N 3
3 LastTraceInformation 3 M 3 M 3 M 3 M 3 N 3
3 intendedRecipient 3 H 3 H 3 H 3 H 3 N 3
3 SupplementaryInfo 3 X/H 3 X 3 X 3 X 3 Y Conformance (E) 3
3MOTIS-> ReassignmentInfo 3 3 3 X 3 3 N 3
3 3 3 3 3 3 3
3MOTIS-> ReassignmentInfo 3 3 3 3 3 3
3MOTIS-> intendedRecipient 3 3 3 M 3 3 N 3
3MOTIS-> reasonForReassignment 3 3 3 H 3 3 N 3
3 3 3 3 3 3 3
3 LastTraceInformation 3 3 3 3 3 3
3 arrival 3 M 3 M 3 M 3 M 3 N 3
3 convertedEncInfoTypes 3 G 3 G 3 H 3 G 3 Y Conformance (E) 3
3 Report 3 M 3 M 3 M 3 M 3 N 3
3 3 3 3 3 3 3
3 Report 3 3 3 3 3 3
3 DeliveredInfo 3 G 3 G 3 G 3 D? 3 N See Note 6 3
3 3 3 3 3 CDM 3 3
3 NonDeliveredInfo 3 G 3 G 3 G 3 DY 3 N 3
3 3 3 3 3 3 3
3 DeliveredInfo 3 3 3 3 3 3
3 delivery 3 M 3 M 3 M 3 M 3 N 3
3 TypeofUA 3 R/H 3 H 3 R 3 M/G 3 N 3
3 3 3 3 3 3 3
3 NonDeliveredInfo 3 3 3 3 3 3
3 ReasonCode 3 M 3 M 3 M 3 M 3 N 3
3 DiagnosticCode 3 H 3 H 3 H 3 H 3 N 3
3MOTIS-> UAprofileIdentifier 3 3 3 X 3 3 N 3
3 3 3 3 3 3 3
3MOTIS-> UAprofileIdentifier 3 3 3 3 3 3
3MOTIS-> ContentType 3 3 3 M 3 3 N 3
3MOTIS-> EncodedInfoTypes 3 3 3 M 3 3 N 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDADDDDDADDDDDDDADDDDDDADDDDDDADDDDDDDDDDDDDDDDDDDDY
(Continued on next page.)
Table 7E.2 Protocol element comparison of P1, continued
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDBDDDDDBDDDDDDDBDDDDDDBDDDDDDBDDDDDDDDDDDDDDDDDDDD?
3P1 Protocol 3 NBS 3 A/311 3A/32113 TTC 3 PROBLEM (Y/N) 3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEDDDDDEDDDDDDDEDDDDDDEDDDDDDEDDDDDDDDDDDDDDDDDDDD4
3 3 3 3 3 3 3
3 ProbeEnvelope 3 3 3 3 3 3
3 probe 3 M 3 M 3 M 3 M 3 N 3
3 originator 3 M 3 M 3 M 3 M 3 N 3
3 ContentType 3 M 3 M 3 M 3 M 3 N 3
3 UAcontentID 3 H 3 H 3 H 3 H 3 N 3
3 originalEncInfoTypes 3 G 3 H 3 H 3 G 3 Y Conformance (E) 3
3 TraceInformation 3 M 3 M 3 M 3 M 3 N 3
3 PerMessageFlag 3 G 3 G 3 G 3 G 3 N 3
3 ContentLength 3 H 3 H 3 H 3 H 3 N 3
3 PerDomainBilatInfo 3 X 3 X 3 X 3 X 3 N 3
3 RecipientInfo 3 M 3 M 3 M 3 M 3 Y TTC 256 max 3
3MOTIS-> InternalTraceInfo 3 M/P 3 3 P 3 3 N 3
3 3 3 3 3 3 3
3 RecipientInfo 3 3 3 3 3 3
3 RecipientORname 3 M 3 M 3 M 3 M 3 N 3
3 ExtensionIdentifier 3 M 3 M 3 M 3 M 3 N 3
3 PerRecipientFlag 3 M 3 M 3 M 3 M 3 N 3
3 ExplicitConversion 3 X 3 X 3 X 3 X 3 N 3
3MOTIS-> OriginatorReqAlternatRecip3 3 3 X 3 3 N 3
3MOTIS-> ReassignmentInfo 3 3 3 X 3 3 N 3
3 3 3 3 3 3 3
3 PerRecipientFlag 3 3 3 3 3 3
3 ResponsibilityFlag 3 M 3 M 3 M 3 M 3 N 3
3 ReportRequest 3 M 3 M 3 M 3 M 3 N 3
3 UserReportRequest 3 M 3 M 3 M 3 M 3 N 3
3 3 3 3 3 3 3
3 TraceInformation 3 3 3 3 3 3
3 3 3 3 3 3 3
3 GlobalDomainIdent 3 M 3 M 3 M 3 M 3 N 3
3 DomainSuppliedInfo 3 M 3 M 3 M 3 M 3 N 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDADDDDDADDDDDDDADDDDDDADDDDDDADDDDDDDDDDDDDDDDDDDDY
(Continued on next page.)
Table 7E.2 Protocol element comparison of P1, continued
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDBDDDDDBDDDDDDDBDDDDDDBDDDDDDBDDDDDDDDDDDDDDDDDDDD?
3P1 Protocol 3 NBS 3 A/311 3A/32113 TTC 3 PROBLEM (Y/N) 3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEDDDDDEDDDDDDDEDDDDDDEDDDDDDEDDDDDDDDDDDDDDDDDDDD4
3 3 3 3 3 3 3
3 DomainSuppliedInfo 3 3 3 3 3 3
3 arrival 3 M 3 M 3 M 3 M 3 N 3
3 deferred 3 X 3 X 3 X 3 X 3 N 3
3 action 3 M 3 M 3 M 3 M 3 N 3
3 (0=relayed) 3 G 3 G 3 G 3 3 N Note: 3
3 3 3 3 3 3 Re-routing not 3
3 3 3 3 3 3 required. 3
3 (1=rerouted) 3 H 3 H 3 H 3 3 N 3
3MOTIS-> (2=recipientReassigned) 3 3 3 H 3 3 N 3
3 converted 3 H 3 G 3 H 3 H 3 Y Conformance(US)3
3 previous 3 H 3 G 3 G 3 X 3 Y Conformance(US)3
3 3 3 3 3 3 (Note: G is 3
3 3 3 3 3 3 inconsistent with3
3 3 3 3 3 3 action (relayed) 3
3 3 3 3 3 3 being "H".) 3
3 3 3 3 3 3 3
3 ORname 3 3 3 3 3 3
3 3 3 3 3 3 3
3 EncodedInformationTypes 3 3 3 3 3 3
3 BitString 3 M 3 M 3 M 3 M 3 N See Note 3 3
3 G3NonBasicParameters 3 X 3 X 3 X 3 X 3 N 3
3 TeletexNonBasicParams 3 X 3 R 3 X 3 X 3 Y Conformance(US)3
3 PresentationAbilities 3 X 3 X 3 X 3 X 3 N 3
3 3 3 3 3 3 3
3 DeliveryReportMPDU 3 G 3 G 3 M 3 G 3 N 3
3 DeliveryReportEnvelop 3 M 3 M 3 M 3 M 3 N 3
3 DeliveryReportContent 3 M 3 M 3 M 3 M 3 N 3
3 3 3 3 3 3 3
3 DeliveryReportEnvelope 3 3 3 3 3 3
3 report 3 M 3 M 3 M 3 M 3 N 3
3 originator ORname 3 M 3 M 3 M 3 M 3 N 3
3 TraceInformation 3 M 3 M 3 M 3 M 3 N 3
3 InternalTraceInfo 3 M/P 3 3 P 3 3 N 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDADDDDDADDDDDDDADDDDDDADDDDDDADDDDDDDDDDDDDDDDDDDDY
(Continued on next page.)
Table 7E.3 Protocol element comparison of P2
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDBDDDDDBDDDDDDDBDDDDDDBDDDDDDBDDDDDDDDDDDDDDDDDDDD?
3P2 Protocol 3 NBS 3 A/311 3A/32113 TTC 3 PROBLEM (Y/N) 3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEDDDDDEDDDDDDDEDDDDDDEDDDDDDEDDDDDDDDDDDDDDDDDDDD4
3 3 3 3 3 3 3
3 UAPDU 3 3 3 3 3 3
3 IM_UAPDU 3 G 3 G 3 G 3 G 3 N 3
3 SR_UAPDU 3 X 3 X 3 X 3 X 3 N 3
3 3 3 3 3 3 3
3 IM_UAPDU 3 3 3 3 3 3
3 Heading 3 M 3 M 3 M 3 M 3 N 3
3 Body 3 M 3 M 3 M 3 M 3 N 3
3 3 3 3 3 3 3
3 Heading 3 3 3 3 3 3
3 IPmessageID 3 M 3 M 3 M 3 M 3 N 3
3 Originator ORname 3 R 3 R 3 R 3 M/G 3 N 3
3 AuthorizingUsers 3 H 3 H 3 H 3 H 3 Y TTC 16 max 3
3 PrimaryRecipients 3 G 3 G 3 G 3 G 3 Y TTC 256 max 3
3 CopyRecipients 3 G 3 G 3 G 3 G 3 Y TTC 256 max 3
3 BlindCopyRecipients 3 H 3 H 3 H 3 H 3 Y TTC 256 max 3
3 InReplyTo 3 G 3 G 3 G 3 G 3 N 3
3 Obsoletes 3 H 3 H 3 H 3 H 3 Y TTC 8 max 3
3 CrossReferences 3 H 3 H 3 H 3 H 3 Y TTC 8 max 3
3 Subject 3 G 3 G 3 G 3 G 3 N 3
3 ExpiryDate 3 H 3 H 3 H 3 H 3 N 3
3 ReplyBy 3 H 3 H 3 H 3 H 3 N 3
3 ReplyToUsers 3 H 3 H 3 H 3 H 3 Y TTC 32 max 3
3 Importance 3 H 3 H 3 H 3 H 3 N 3
3 Sensitivity 3 H 3 H 3 H 3 H 3 N 3
3 Autoforwarded 3 H 3 H 3 H 3 H 3 N 3
3MOTIS-> CirculationList 3 3 3 X 3 3 N 3
3MOTIS-> ObsoletingTime 3 3 3 X 3 3 N 3
3 3 3 3 3 3 3
3 IPmessageID 3 3 3 3 3 3
3 ORname 3 H 3 H 3 H 3 H 3 N 3
3 PrintableString 3 M 3 M 3 M 3 M 3 N 3
3 3 3 3 3 3 3
3 ORdescriptor 3 3 3 3 3 3
3 ORname 3 H 3 H 3 H 3 D? 3 N See Note 6 3
3 3 3 3 3 CDM 3 3
3 FreeFormName 3 H 3 H 3 H 3 DY 3 N 3
3 TelephoneNumber 3 H 3 H 3 H 3 G 3 N 3
3 3 3 3 3 3 3
3 Recipient 3 3 3 3 3 3
3 ORdescriptor 3 M 3 M 3 M 3 M 3 N 3
3 ReportRequest 3 X 3 X 3 X 3 X 3 N 3
3 ReplyRequest 3 H 3 H 3 H 3 H 3 N 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDADDDDDADDDDDDDADDDDDDADDDDDDADDDDDDDDDDDDDDDDDDDDY
(Continued on next page.)
Table 7E.3 Protocol element comparison of P2, continued
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDBDDDDDBDDDDDDDBDDDDDDBDDDDDDBDDDDDDDDDDDDDDDDDDDD?
3P2 Protocol 3 NBS 3 A/311 3A/32113 TTC 3 PROBLEM (Y/N) 3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEDDDDDEDDDDDDDEDDDDDDEDDDDDDEDDDDDDDDDDDDDDDDDDDD4
3MOTIS-> CirculationList 3 3 3 3 3 3
3MOTIS-> CirculationMember 3 3 3 X 3 3 N 3
3MOTIS-> checkmark 3 3 3 M 3 3 N 3
3MOTIS-> membername 3 3 3 M 3 3 N 3
3 3 3 3 3 3 3
3MOTIS-> OBsoletingTime 3 3 3 3 3 3
3MOTIS-> Time 3 3 3 H 3 3 N 3
3MOTIS-> IP_MessageID 3 3 3 H 3 3 N 3
3 3 3 3 3 3 3
3 Body 3 3 3 3 3 3
3 BodyPart 3 G 3 M 3 M 3 G 3 Y Conformance (US)3
3 3 3 3 3 3 3
3 SR_UAPDU 3 3 3 3 3 3
3 NonReceipt 3 H 3 H 3 H 3 D? 3 N 3
3 3 3 3 3 CDM 3 3
3 Receipt 3 H 3 H 3 H 3 DY 3 N 3
3 Reported 3 M 3 M 3 M 3 M 3 N 3
3 ActualRecipient 3 R 3 R 3 R 3 G 3 N 3
3 IntendedRecipient 3 H 3 H 3 H 3 H 3 N 3
3 Converted 3 X 3 X 3 X 3 G 3 N 3
3MOTIS-> CirculationStatus 3 3 3 X 3 3 N 3
3 3 3 3 3 3 3
3 NonReceiptInformation 3 3 3 3 3 3
3 Reason 3 M 3 M 3 M 3 M 3 N 3
3 NonReceiptQualifier 3 H 3 H 3 H 3 H 3 N 3
3 =expired (value) 3 0 3 0 3 0 3 0 3 N 3
3 =obsoleted (value) 3 1 3 1 3 1 3 1 3 N 3
3 =subscriptionTerminated 3 2 3 2 3 2 3 2 3 N 3
3MOTIS-> =timeobsoleted (value) 3 3 3 X 3 3 N 3
3 Comments 3 H 3 H 3 H 3 X 3 N 3
3 returned 3 H 3 X 3 X 3 X 3 Y Conformance (E) 3
3 3 3 3 3 3 3
3 ReceiptInformation 3 3 3 3 3 3
3 Receipt 3 M 3 M 3 M 3 M 3 N 3
3 TypeOfReceipt 3 H 3 H 3 H 3 G 3 N 3
3 SupplementaryInfo 3 X 3 X 3 X 3 X 3 N 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDADDDDDADDDDDDDADDDDDDADDDDDDADDDDDDDDDDDDDDDDDDDDY
(Continued on next page.)
Table 7E.3 Protocol element comparison of P2, continued
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDBDDDDDBDDDDDDDBDDDDDDBDDDDDDBDDDDDDDDDDDDDDDDDDDD?
3P2 Protocol 3 NBS 3 A/311 3A/32113 TTC 3 PROBLEM (Y/N) 3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEDDDDDEDDDDDDDEDDDDDDEDDDDDDEDDDDDDDDDDDDDDDDDDDD4
3 3 3 3 3 3 3
3 BODYPART SUPPORT 3 3 3 3 3 3
3 3 3 3 3 3 3
3 o IA5 Text 3 G 3 G 3 G 3 3 N See Note 7 3
3 o TLX 3 X 3 X 3 X 3 3 N 3
3 o Voice 3 X 3 X 3 X 3 3 N 3
3 o G3FAX 3 X 3 X 3 X 3 3 N 3
3 o TIFO 3 X 3 X 3 X 3 3 N 3
3 o TTX 3 X 3 X/H 3 X 3 3Y Conf(US)See Note 23
3 o VideoTex 3 X 3 X 3 X 3 3 N 3
3 o NationallyDefined 3 X 3 X 3 X 3 3 N 3
3 o Encrypted 3 X 3 X 3 X 3 3 N 3
3 o ForwardedIPmessage 3 H 3 H 3 H 3 3 N 3
3 o SFD 3 X 3 X 3 X 3 3 N 3
3 o TIFI 3 X 3 X 3 X 3 3 N 3
3 3 3 3 3 3 3
3MOTIS-> o ODA 3 3 3 X 3 3 N 3
3MOTIS-> o ISO6937 Text 3 3 3 H 3 3 N 3
3 3 3 3 3 3 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDADDDDDADDDDDDDADDDDDDADDDDDDADDDDDDDDDDDDDDDDDDDDY
Note 1: It should be noted that the A/311 profile states: For routing
all ADMDs should support all Form 1 Variants of O/R Name. All
PRMDs should support at least Form 1, Variant 1 form of OR Name.
Note 2: It should also be noted that the A/311 profile requires that all
ADMDs should support the reception of Teletex body parts for
delivery to their own UAEs.
Note 3: An A/3211 implementation may generate MOTIS encoded information
types. See 7.6.11.
Note 4: Only Form 1 Variant 1 of O/Rname shown for TTC, but TTC defines
other forms and variants. Form 1 Variant 1 recommended for PRMDs
and ADMDs, Form 1 Variant 2 also recommended for ADMDs.
Note 5: DDA's can be used to specify recipients in any Japanese domains
other than TTC. Assignment of DDAs for UAs within TTC domains is
not recommended.
Note 6: One of [DeliveredInfo/NonDeliveredInfo] must be present. TTC
encodes this as shown. Other profiles represent this by
classifying both protocol elements as generatable. A similar
situation exists with the P2 ORdescriptor.
Note 7: TTC is expected to support IA5 for some international MHS
communications.
7.16 APPENDIX F: INTERWORKING WARNINGS
ADMD name is to be encoded as a single space when configurations with
no ADMD's are present. It should be noted that this may change in
January 1988 so that the ADMD name is encoded as a zero length element
in such cases.
The NBS agreements allow implementation to generate MPDUs with no
body parts. Such MPDUs will be rejected by European-conformant
systems. (Note this situation may change in January 1988)
In order to optimize the number of recipients you can read and reply
to, it is advisable to be able to generate all standard O/R name
attributes.
8. DIRECTORY SERVICES PROTOCOLS
8.1 INTRODUCTION
This is an Implementation Agreement developed by the Implementor's
Workshop sponsored by the U.S. National Bureau of Standards to promote
the useful exchange of data between devices manufactured by different
vendors. This agreement is based on and employs protocols developed
in accord with the OSI Reference Model. While this agreement
introduces no new protocols, it eliminates ambiguities in
interpretations.
This is an Implementation Agreement for Directories based on the ISO
documents cited in the Reference Section 11.1 (hereafter referenced as
Directory documents). Versions of this document will stay consistent
with the latest drafts of those Directory Documents. Figure 8.1
displays the structure of this Implementation Agreement. References
to corresponding CCITT documents are included for information.
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDBDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 Directory Access Protocol 3 Directory System Protocol 3
3 (DAP) 3 (DSP) 3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDADDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3 Remote Operations Services and Protocols 3
3 (CCITT X.219 and X.229/ISO 9072/1 and 9072/2) 3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3 Association Control Services and Protocols 3
3 (CCITT X.217 and X.227/ISO 8649 and 8650) 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
Figure 8.1 Structure of this Implementation Agreement
The Directory User Agents (DUAs) and Directory System Agents (DSAs)
provide access to the Directory on behalf of humans and applications
such as Message Handling and File Transfer, Access, and Management.
See the Scope and Field of Application section for more information on
the model used in Directories.
This document covers both the Directory Access Protocol (DAP) and the
Directory System Protocol(DSP) defined in the Directory documents. A
good working knowledge of the Directory documents is assumed by this
chapter. All terminology and abbreviations used but not defined in
this text may be found in those documents.
8.2 SCOPE AND FIELD OF APPLICATION
Centralized and distributed directories can both be accommodated in
this Agreement by the appropriate choice of protocols and pragmatic
constraints from those specified. Figure 8.2 illustrates a
centralized directory and Figure 8.3 illustrates a distributed
directory.
This agreement does not cover interaction between co-located entities,
such as a co-resident DUA and DSA. It also does not specify the
interface between a user (person or application) and a DUA.
Bilateral agreements between a DUA and DSA or DSA and DSA may be
implemented in addition to the requirements stated in this document.
Conformance to this agreement requires the ability to interact
without the use of bilateral agreements other than those required in
the Directory documents.
The logical structure of the Directory Information Base (DIB) is
described in the Directory documents. The manner in which a local
portion of the DIB is organized and accessed by its DSA is not in the
scope of this agreement.
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 3
3 00000000000000000000000 3
3 0 The Directory 0 3
3 0 0 3
3 0 ZDDDDDDDDDDD? 0 3
3 ZDDDDDDDDDDD? ZDDDDDDDDDD? 0 3 3 0 3
3 3 USER 3<DDD>3 DUA 3<DDD0DDD>3 3 0 3
3 @DDDDDDDDDDDY @DDDDDDDDDDY 0 3 DSA 3 0 3
3 ZDDDDDDDDDDD? ZDDDDDDDDDD? 0 3 3 0 3
3 3 USER 3<DDD>3 DUA 3<DDD0DDD>3 3 0 3
3 @DDDDDDDDDDDY @DDDDDDDDDDY 0 @DDDDDDDDDDDY 0 3
3 0 0 3
3 0 0 3
3 00000000000000000000000 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
Figure 8.2 Centralized Directory Model
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 3
3 ZDDDDDDD? 3
3 3 User 3 3
3 @DDDBDDDY 3
3 3 3
3 ZDDDADDD? 3
3 3 DUA 3 3
3 @DDDBDDDY 3
3 3 3
3ZDDDDDD? ZDDDDDDD?0000000000000000000000000000000 3
33 User CDD4 DUA 30The Directory 3 0 3
3@DDDDDDY @DDDDDDDY0 3 0 3
3 0 ZDDDADDD? 0 3
3 0 3 DSA 3 0 3
3 0 @DDDDDDDY 0 3
3 0ZDDDDDDD? ZDDDDDDD?0 3
3 03 DSA 3 3 DSA 30 3
3 0@DDDDDDDY @DDDDDDDY0 3
3ZDDDDDD? ZDDDDDDD?0 ZDDDDDDD? 0ZDDDDDDD? ZDDDDDD?3
33 User CDD4 DUA 30 3 DSA 3 03 DUA CDD4 User 33
3@DDDDDDY @DDDDDDDY0 @DDDDDDDY 0@DDDDDDDY @DDDDDDY3
3 0000000000000000000000000000000 3
3 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
Figure 8.3 Distributed Directory Model
8.3 STATUS
This version was completed on December 18, 1987.
8.4 Use of Directories
Given the rapid multiplication and expansion of OSI applications,
telecommunication systems and services, there is growing need for
users of, as well as the applications themselves, to communicate with
each other. In order to facilitate their communications, a Directory
protocol, as referenced in these agreements, has been tailored to meet
their respective needs.
In one instance, Directories will be used as a service to provide
humans, in an on-line fashion, rapid and easy retrieval of information
useful for determining what telecommunications services are available,
and/or how to access, and address their correspondents. Further,
service providers offering such a Public Directory may also use this
service internally with other various telecommunications services
(e.g., MHS) for the proper addressing of calls or messages. Likewise,
this does not preclude the usage of these agreements to similarly
generate a privately operated Directory that supports both human and
application information exchanges.
In another instance, Directories, will be used as a service by
computer applications without direct human involvement. One important
service is to provide Presentation Address resolution for named
objects, on behalf of OSI applications. The directory may be used by
applications to search for objects (i.e., Application Entities),
without direct human involvement, by the use of the "search" or
"list" operations.
To support the many possible usages, the Directory is a general
purpose system. It is capable of storing data of many different
forms as attributes within entries, and is also capable of supporting
simple or complex hierarchical structures, with variations in
structure possibly occurring between one part of the Directory and
another.
Compliant DSA implementations should safeguard this generality, where
possible, by placing the minimum of restrictions in "hard-wired"
form. The Directory permits the imposition of rules by means of the
Directory Schema (Section 8.6 below); but the Directory Schema
itself should be capable of alteration by Directory management.
8.5 Directory ASEs, Application Contexts, and Ports
The following section is included for tutorial purposes. The
functionality of the Directory AEs (DUAs and DSAs) is defined by a set
of ASEs, each Directory ASE specifying a set of Directory operations.
The interaction between these AEs is described in terms of their use
of ASEs. This specific combination of a set of ASEs and the rules for
their usage defines an application context.
Thus, each Directory application context defines the operations needed
by two communicating Directory entities.
Access to the services provided by an application context is through
one or more directory ports. The point of access is called an Access
Point (see Figure 8.4). Each access point corresponds to a
particular combination of port types.
The following ASEs are described in the Directory Document:
o Directory Read ASE
o Directory Chained Read ASE
o Directory Search ASE
o Directory Chained Search ASE
o Directory Modify ASE
o Directory Chained Modify ASE
ROSE and ACSE also form part of the Directory Application Contexts.
The following Application Contexts are described in the Directory
Document:
o Directory Access Application Context
o Directory System Application Context
The following Ports are described in the Directory Document:
o Read Port
o Modify Port
o Search Port
o Chained Read Port
o Chained Search Port
o Chained Modify Port
The ports cited above are to be specified for a particular Access
Point to the Directory as illustrated by Figure 8.4.
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 Access Point DDDDDDDDD? 3
3 3 3
3 ZDDDDDDDDDDDDDDDD? 3ZDDDDDDDDDDDDDDD? 3
3 3 3 33 3 3
3 3 Directory ZDDDDADDDDD? 33 3 3
3 3 user 3 3 3 The 3 3
3 3 3 DUA CDDDDDDDDDDDDD4 Directory 3 3
3 3 3 3 3 3 3
3 3 @DDDDBDDDDDY 3 3 3
3 3 3 3 3 3
3 @DDDDDDDDDDDDDDDDY @DDDDDDDDDDDDDDDY 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
Figure 8.4 Access to the Directory
8.6 Schemas
There are four (4) major topics that relate to schemas:
8.6.1 Maintenance of Structures and Naming Rules
DSAs shall be capable of supporting the object classes and the
associated structure and naming rules defined in the Directory
documents, part 7, annex B, in the sense that DITs may be
constructed and within these rules shall be supported.
8.6.2 Maintenance of object classes and subclasses
DSAs shall be able to support the storage and use of the
following object classes defined in the Directory documents part
7, annex B:
top alias
country application entity
locality organizational-person
organization residential-person
organizational unit application-process
DSA
Use of the modification and local extension mechanisms provided
by registered and unregistered object classes is optional.
8.6.3 Maintenance of Attribute Types
DSAs shall be able to support the storage and use of attribute
type information, as defined in Part 6, including their use in
naming and access to entries; they shall also support the
definition of new attribute types, making use of pre-existing
attribute syntaxes.
8.6.4 Maintenance of Attribute Syntaxes
Suggested methods for the interpretation of selected Attribute
Syntaxes are defined in Appendix B.
8.7 Classification of Support for Attribute Types
This section classifies directory support for selected attribute type
specified in the Directory documents.
Classification of support for selected attribute types is either
mandatory or optional.
8.7.1 Mandatory Support
The Directory must be able to support these Attribute Types:
Aliased Object Name Postal Address
Business Category Postal Code
Common Name Preferred Delivery Mode
Country Name Presentation Address
Locality Name Role Occupant
ISDN Address See Also
Member Serial Number
Object Class State or Province Name
Organization Name Street Address
Organizational Unit Name Supported Application Context
Owner Surname
Post Office Box Telephone Number
Title
User Password
X.121 Address
Note: Support of these Attribute Types implies full support
of the relevant Attribute Syntaxes.
8.7.2 Optional Support
Directory support of these attribute types is considered
optional:
Authority Revocation List
CA Certificate
Certificate Revocation List
Description
Destination Indicator
Facsimile Telephone Number
Knowledge Information
Non-Basic Parameters
Physical Delivery Office Name
Registered Address
Search Guide
Teletex Terminal Identifier
Telex Number
User Certificate
Note: DSAs should consider initial support of the Attribute
Syntax relevant to any Attribute Type for which future
support is planned, in addition to those required for
mandatory Attribute Types.
8.8 Introduction to Pragmatic Constraints
The following sections of this document define the pragmatic
constraints to which a conformant implementation must adhere in
addition to those specified in the Directory documents. The pragmatic
constraints are divided into two areas. The first includes those
aspects of pragmatic constraints which apply to the scope of service.
The second includes those aspects of pragmatic constraints which are
specific to particular attribute types.
8.9 General Constraints
8.9.1 Character Sets
It is a requirement to support all character sets and other name
forms defined in the Directory Documents Part 6. Those
character sets include:
o T.61
o PrintableString
o NumericString
8.9.2 APDU Size Considerations
In the process of chaining requests it is possible that a
chaining DSA may receive invoke or return APDUs that exceed its
capacity:
ZDDDDDDDDD? 2k ZDDDDDDDDD? 2k ZDDDDDDDDD?
3 CDDDDDDDDDDDDDD>3 CDDDDDDDDDDDDDDD>3 3
3 DUA 3 3 DSA 3 3 DSA 3
3 3<DDDDDDDDDDDDDD4 ZDE<DDDDDDDDDDDDDDD4 3
@DDDDDDDDDY 37K @DDDDDDDEDY 33K @DDDDDDDDDY
DSA may pass on DSA may discard
Figure 8.5 APDU Exchange
It is a minimum requirement that invoke and return result APDUs
must be accepted unless they exceed 32767 octets in size; in
this case they may be discarded as illustrated in the right side
of figure 8.5, and an "unwillingToPerform" error reporting
service shall be used.
8.9.3 Service Control (SC) Considerations
This agreement recognizes that DUAs may automatically supply
defaults for any SC parameter. The choice of default values
selected (if any) is seen to be a matter of local policy and
consumer needs.
8.9.4 Priority Service Control
Priority is specified as a service control argument in the
Directory documents. The following statements represent a
clarification of the semantics that may be used by a DSA in
interpreting and operating on this parameter.
The logical model in Figure 8.6 may be considered as an example
by DSAs that implement this Service Control.
o The DSA maintains three logical queues corresponding to
the three priority levels.
o The DSA Scheduler is separate and distinct from any
scheduling function provided by the underlying
operating system or control program services.
o The DSA Scheduler presents jobs to the Underlying
Operating Services for execution and always presents
jobs of a higher priority before those of a lower
priority.
o The DSA Scheduler will not preempt a request once it
has been passed to the underlying operating system
service.
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 3
3 ZDDDDDDDDDDDDDDDD? ZDDDDDDDDDDDDD? 3
3 ZDDD>3 High CDDDDD>3 3
3 3 @DDDDDDDDDDDDDDDDY 3 ZDDDDDDDDDDD? 3
3 3 ZDDDDDDDDDDDDDDDD? 3 3 DSA 3 3
3 CDDD>3 Medium CDDDDD>3 3 Scheduler 3 3
3 3 @DDDDDDDDDDDDDDDDY 3 @DDBDDDDDDDDY 3
3 3 ZDDDDDDDDDDDDDDDD? 3 3 3
3 CDDD>3 Low CDDDDD>3 3 3
3 3 @DDDDDDDDDDDDDDDDY 3
3ZDDADDDDDDDDDDDDDDDD? ZDDDDDDDDDDDDDDD? 3
33 Underlying 3 3 Underlying OS 3 3
33 Protocol Services 3 3 Services 3 3
3@DDDDDDDDDDDDDDDDDDDY @DDDDDDDDDDDDDDDY 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
Figure 8.6 Logical DSA Application Environment
8.10 Constraints on Operations
There are no overall constraints upon service arguments or results
except those implied in section 8.9.2 of this document.
8.10.1 Filters
It is required that DSAs, at a minimum, support 8 nested
"Filter" parameters, and a total limit of 32 Filter Items. If
these limits are exceeded, the recipient of that SearchArgument
may return the ServiceProblem "unwillingToPerform".
8.10.2 Errors
There are no constraints upon any Error service except the APDU
size limit as defined in section 8.9.2.
8.11 Constraints on Attribute Types
This section defines the pragmatic constraints specific to particular
attribute types.
8.11.1 Attribute Values
This section describes the pragmatic constraints for attribute
values. Each constraint is given in terms of a Length
Constraint. The Length Constraint for a given attribute value is
the number of units which a sending entity must not exceed and
which a receiving entity must accept and process. A sending
entity need not be capable of sending attribute values as large
as the Length Constraints.
Use of Pragmatic Constraints for Strings
The Length Constraint for strings is expressed as the number of
allowable characters and the number of allowable octets. When
using the Printable String ASN.1 data type, the number of octets
equals the number of characters. When using the T.61 ASN.1 data
type, the number of octets is twice the number of characters.
This is because some T.61 characters occupy two octets per
character.
Attribute Types
Table 8.1 specifies the pragmatic constraints for selected
attribute types specified in the Directory documents; many of
these constraints also appear and are the same in the CCITT
version of the Directory documents.
Alphabets
T.61 Strings used as attribute values shall only encode graphic
characters and spaces. (They must not contain formatting
characters (such as subscript) or other control characters.
Table 8.1 Pragmatic Constraints for Selected Attributes.
ZDDDDDDDDDDDDDDDDDDBDDDDDDDDDDDDDBDDDDDDDDBDDDDDDDDDBDDDDDDDDDBDDDDDDDDDDDDDDD?
3 Attribute Type 3 Content 3 Number 3 Number 3 Status 3 Notes 3
3 3 3 of 3 of 3 3 3
3 3 3 Print- 3 Allow- 3 3 3
3 3 3 able 3 able 3 3 3
3 3 3 Char- 3 Octets 3 3 3
3 3 3 acters 3 3 3 3
CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
3 Object Class 3 Object 3 3 256 3 3 3
3 3 Identifier3 3 3 3 3
CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
3 Common Name 3 T.61 or 3 64 3 128 3 3 X.500 3
3 3 Printable 3 3 3 3 3
3 3 String 3 3 3 3 3
CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
3 Serial Number 3 Printable 3 64 3 64 3 3 X.500 3
3 3 String 3 3 3 3 3
CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
3 Country Name 3 Printable 3 3 3 3 ISO 3166 3
3 3 String 3 2 3 2 3 3 String only 3
CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
3 Locality 3 T.61 or 3 128 3 256 3 3 X.500 3
3 3 Printable 3 3 3 3 3
3 3 String 3 3 3 3 3
CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
3 Postal 3 T.61 or 3 30 x 6 3 60 x 6 3 3 Note 4 3
3 Address 3 Printable 3 3 3 3 X.500 & UPU 3
3 3 String 3 3 3 3 3
3 3 3 3 3 3 3
CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
3 Postal Code 3 T.61 or 3 40 3 80 3 3 UPU 3
3 3 Printable 3 3 3 3 X.500 3
3 3 String 3 3 3 3 3
CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
3 Organization 3 T.61 or 3 64 3 128 3 3 X.500 3
3 Name 3 Printable 3 3 3 3 3
3 3 String 3 3 3 3 3
CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
3 Organizational 3 T.61 or 3 64 3 128 3 3 X.500 3
3 Unit Name 3 Printable 3 3 3 3 3
3 3 String 3 3 3 3 3
@DDDDDDDDDDDDDDDDDDADDDDDDDDDDDDDADDDDDDDDADDDDDDDDDADDDDDDDDDADDDDDDDDDDDDDDDY
Table 8.1 Pragmatic Constraints for Selected Attributes. (continued)
ZDDDDDDDDDDDDDDDDDDBDDDDDDDDDDDDDBDDDDDDDDBDDDDDDDDDBDDDDDDDDDBDDDDDDDDDDDDDDD?
3 Attribute Type 3 Content 3 Number 3 Number 3 Status 3 Notes 3
3 3 3 of 3 of 3 3 3
3 3 3 Print- 3 Allow- 3 3 3
3 3 3 able 3 able 3 3 3
3 3 3 Char- 3 Octets 3 3 3
3 3 3 acters 3 3 3 3
CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
3 Title 3 T.61 or 3 64 3 128 3 3 X.500 3
3 3 Printable 3 3 3 3 3
3 3 String 3 3 3 3 3
CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
3 Description 3 T.61 or 3 1024 3 2048 3 3 X.500 About 3
3 3 Printable 3 3 3 3 1 Screen full3
3 3 String 3 3 3 3 3
CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
3 Search Guide 3 3 3 3 3 ffs 3
CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
3 Business Category3 T.61 or 3 64 3 128 3 3 3
3 3 Printable 3 3 3 3 3
3 3 String 3 3 3 3 3
CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
3 Facsimile Tele- 3 Facsimile 3 3 ffs 3 3 CCITT E.163 3
3 phone Number 3 Telephone 3 3 3 3 X.500 3
3 3 Number 3 3 3 3 Includes G3 3
3 3 3 3 3 3 Non Basic 3
3 3 3 3 3 3 Parameters 3
CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
3 ISDN Address 3 Numeric 3 n/a 3 16+40 3 3 CCITT 3
3 3 String 3 3 3 3 E. 164 X.500 3
CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
3 Presentation 3 Presen- 3 n/a 3 224 3 3Note 2,ISO 74983
3 Address 3 tation 3 3 3 3X.500, & X.200 3
3 3 Address 3 3 3 3 3
CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
3 Telephone 3 Printable 3 32 3 32 3 3 CCITT E.163 3
3 Number 3 String 3 3 3 3 X.500 3
CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
3 Teletex Terminal 3 Teletex 3 3 ffs 3 3 CCITT F.200 3
3 Identifier 3 Terminal 3 3 3 3 X.500 3
3 3 Identifier3 3 3 3 Includes 3
3 3 3 3 3 3 Teletex Non 3
3 3 3 3 3 3 Basic 3
3 3 3 3 3 3 Parameters 3
@DDDDDDDDDDDDDDDDDDADDDDDDDDDDDDDADDDDDDDDADDDDDDDDDADDDDDDDDDADDDDDDDDDDDDDDDY
Table 8.1 Pragmatic Constraints For Selected Attributes. (continued)
ZDDDDDDDDDDDDDDDDDDBDDDDDDDDDDDDDBDDDDDDDDBDDDDDDDDDBDDDDDDDDDBDDDDDDDDDDDDDDD?
3 Attribute Type 3 Content 3 Number 3 Number 3 Status 3 Notes 3
3 3 3 of 3 of 3 3 3
3 3 3 Print- 3 Allow- 3 3 3
3 3 3 able 3 able 3 3 3
3 3 3 Char- 3 Octets 3 3 3
3 3 3 acters 3 3 3 3
CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
3 3 Telex 3 3 3 3 CCITT X.500 3
3 Telex Number 3 Number 3 3 ffs 3 3 X.121 3
3 3 3 3 3 3 Contains 3
3 3 3 3 3 3 telex-number,3
3 3 3 3 3 3 country code,3
3 3 3 3 3 3 answer back 3
CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
3 X.121 Address 3 Numeric 3 15 3 15 3 3 CCITT X.121 3
3 3 3 3 3 3 X.500 3
CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
3 Member 3 Distin- 3 3 3 3 Note 3 3
3 3 guished 3 3 3 3 3
3 3 Name 3 3 3 3 3
CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
3 Owner 3 Distin- 3 3 3 3 Note 3 3
3 3 guished 3 3 3 3 3
3 3 Name 3 3 3 3 3
CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
3 Role 3 Distin- 3 3 3 3 Note 3 3
3 Occupant 3 guished 3 3 3 3 3
3 3 Name 3 3 3 3 3
CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
3 See Also 3 Distin- 3 3 3 3 Note 3 3
3 3 guished 3 3 3 3 3
3 3 Name 3 3 3 3 3
CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
3 User 3 Octet 3 n/a 3 128 3 3X.500 Allow 3
3 Password 3 String 3 3 3 3long passwords.3
3 3 3 3 3 3Machine 3
3 3 3 3 3 3Generated 3
CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
3 Aliased Object 3 Distin- 3 3 3 3 Note 3 3
3 Name 3 guished 3 3 3 3 3
3 3 Name 3 3 3 3 3
CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
3 Knowledge 3 T.61 or 3 1024 3 2048 3 3 About 1 3
3 Information 3 Printable 3 3 3 3 screen full. 3
3 3 String 3 3 3 3 ffs 3
@DDDDDDDDDDDDDDDDDDADDDDDDDDDDDDDADDDDDDDDADDDDDDDDDADDDDDDDDDADDDDDDDDDDDDDDDY
Table 8.1 Pragmatic Constraints For Selected Attributes. (continued)
ZDDDDDDDDDDDDDDDDDDBDDDDDDDDDDDDDBDDDDDDDDBDDDDDDDDDBDDDDDDDDDBDDDDDDDDDDDDDDD?
3 Attribute Type 3 Content 3 Number 3 Number 3 Status 3 Notes 3
3 3 3 of 3 of 3 3 3
3 3 3 Print- 3 Allow- 3 3 3
3 3 3 able 3 able 3 3 3
3 3 3 Char- 3 Octets 3 3 3
3 3 3 acters 3 3 3 3
CDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDEDDDDDDDDDEDDDDDDDDDEDDDDDDDDDDDDDDD4
3 3 3 3 3 3 3
3 Street Address 3 T.61 or 3 3 3 3UPU. Component 3
3 3 Printable 3 3 3 3of Postal 3
3 3 String 3 3 3 3Address 3
@DDDDDDDDDDDDDDDDDDADDDDDDDDDDDDDADDDDDDDDADDDDDDDDDADDDDDDDDDADDDDDDDDDDDDDDDY
Notes:
1. The pragmatic constraints of these parameters are defined in
other standards. We will accommodate these values in our
pragmatic constraints.
2. Presentation address is composed of "X" NSAP addresses, and
three selectors, (20X + 32 + 16 + 16 ), e.g. if X = 1, this would
be 84. These numbers are based on the most recent implementor's
agreements. With 8 NSAP addresses this value is 224.
3. Pragmatic constraints are only applied to the individual
components of DistinguishedName as defined in the Directory
Documents Part 2. Not all components of a DN will necessarily be
understood by an implementation.
4. Implementors should be aware that constraints on Postal Address
may not be sufficient for some markets.
8.12 Conformance
The following sections will describe various aspects of Directory
conformance. It should be noted that conformance to the various ASEs
and conformance to the Authentication Framework are viewed as separate
issues and are presented in that context.
8.12.1 DUA Conformance
Conformance requirements for DUAs are adequately specified in the
Directory documents, Part 5, section 9.1. It should be noted
that DUA conformance can only be demonstrated by exercising the
interface that it provides to its user.
It is recognized that DUAs will be widely differing in nature:
o Some are intended to support human users, some application
users
o Particular DUAs may not support particular operations
because the application that they support has no
requirement; others will be general purpose, and will
support all operations.
o Some DUAs will have a fixed view of the Directory content
and structure, reflecting the usage of the Directory by a
particular application; others will have a more flexible
view which can be adapted to new usages.
o Some DUAs will provide automatic referral services with
automatic establishment and release of associations; others
will place the burden on the user.
o Some DUAs will provide a variety of authentication means;
others will support simple authentication only
o Some DUAs will handle operations synchronously; others will
have the capability of maintaining several identifiable
dialogues with the Directory at one time.
No general implementation agreements are spelled out in respect
of these possibilities.
8.12.2 DSA Conformance
Basic conformance requirements for a DSA are defined in the
Directory documents, Part 5, section 9.2.
Centralized
A centralized DSA is defined as one that contains its entire
relevant DIT; it follows that it will not make use of the DSP or
generate referral responses. Since this model only contains a
single DSA it is not subject to DSA interworking issues and will
always provide a consistent level of service and results. A
centralized DSA must be fully "protocol" conformant to the DAP.
Cooperating
In a distributed directory, responsibility for various portions
of the DIT may be "distributed" among multiple DSAs. On a per
operation basis we define a DSA to be "holding" when it is
responsible for the fragment of the DIB in which a given entry
will appear if it exists; we define a DSA to be "propagating"
when it is unable to complete the name resolution process. All
DSAs must be capable of acting as a "holder" and a"propagator."
8.12.3 Directory Systems Conformance Classes
A DSA implementation shall satisfy the conformance requirements
as defined in the Directory documents, part 5, section 9.2, and
shall support the "Versions" argument of "Bind".
Additionally, an implementation conformant to these agreements
shall state which of the following conformance classes it
implements:
Conformance Class 0: Centralized Directory
A DSA implementation conformant to this class only supports the
DirectoryAccessAC. It must implement all operations in the Read
and Modify ASEs. Optionally, it may implement the operations in
the Search ASE.
A DSA that does not support the Search and List operations must
reply to such operations with an unwillingToPerform service
error.
Conformance Class 1: Distributed Directories
A DSA implementation conformant to this class must implement all
the operations in the ASEs that are part of the Application
context for which it claims conformance. It must support the
DirectoryAccessAC and it may optionally support the
DirectorySystemAC.
8.12.4 Authentication Conformance
A Directory System may choose to implement various levels of
authentication (Directory documents, Part 8). We define the
following four (4) levels of authentication in the DS:
o No authentication at all; (None)
o Identification of the remote peer entity only, without
verification; (Weak)
o Simple authentication: verified identification with or
without a password. Intended to make masquerading
difficult; and
o Strong authentication: identification with verification
using cryptographic techniques intended to make
masquerading, in practical terms, nearly impossible.
The Authentication Framework document describes the specific goal
of each authentication level; we have listed several practical
uses of the various levels:
NONE No authentication may be required for associations with
a DSA containing public information: DSAs operating on
a private network in a controlled environment may
implicitly trust all connections and have no
requirement for authentication.
WEAK authentication may be desired to maintain access
statistics or in a private network where the initiator
is implicitly trusted and there is no need to incur
the additional overhead of more sophisticated
authentication methods.
SIMPLE authentication may be necessary in situations where
strong authentication is not practical, (i.e.:
international connections, no knowledge of algorithms
in use, etc).
STRONG authentication will be required for secure
environments.
8.12.5 Authentication Conformance Classes
We define the following two (2) conformance classes for the
support of authentication:
o None, Weak,
o None, Weak, and Simple (unprotected)
Consideration of protected simple and strong authentication is
not part of this agreement.
8.13 Distributed Operations
The following requirements apply to DSAs supporting distributed
operations:
1. DSAs must support the generation of referrals.
2. DSAs may additionally support chaining. DSAs that only support
chaining (i.e. no referrals) are not allowed.
3. DSAs supporting authentication (e.g. simple authentication by
name and password) must be able to invoke DSP operations to carry
out authentication by reference to other DSAs. Thus all such
DSAs must support the DSP protocol.
8.13.1 Referrals and Chaining
It is recommended that a DSA which has chained a request act upon
any referrals it receives rather that returning them to the
requestor if the "PreferChaining" service control is present.
8.14 Underlying Services
8.14.1 ROSE
It should be noted that support of "abandon" implies support of
operation class 2.
8.14.2 Session
All directory implementations are required to support Session
Version 2.
8.15 Access Control
Guidelines relation to access control can be found in annex F of the
Directory documents, part 2.
8.16 Authentication
Simple Authentication, as defined in Part 8 of the Directory
documents, encompasses both Weak and Simple Authentication, as called
for by section 8.12. (This shall be taken to imply unprotected simple
authentication.)
A DSA that implements Simple Authentication as called for in section
8.12, will check a user password, (if one is supplied) by means of a
compare operation on the user's entry or otherwise; if no user
password is supplied, the DSA will validate the presence of an entry
for the user, by a read operation or otherwise; the authentication
will fail if the password is incorrect, or if the user's entry does
not exist. DSP must be used when the user's entry is not a local
entry; this form of authentication is therefore not normally
appropriate for DAP only DSAs.
A DSA that implements Weak Authentication will accept simple
credentials without validating them.
8.17 Test Considerations
This section outlines some items that implementors may wish to
consider in terms of testing expectations; additionally, future
conformance testers may wish to consider these items when developing
tests.
8.17.1 Major elements of Architecture
One important aspect of testing is to confirm the correct
behavior of DSAs and DUAs in respect of major elements of the
directory architecture.
Such major elements include:
o Conformance Statement
o Distinguished names (e.g., name resolution, equivalence of
various forms)
o Entries and Attributes (e.g., accessibility by operations,
compliance with rules)
o Handling of distributed operations (e.g.,naming contexts
and knowledge)
o Schemas
- Structure rules (e.g., storage and maintenance of
structure and of naming)
- Object classes and sub-classes (e.g., storage and
extension of rules for object attributes)
- Attribute types (e.g., storage and maintenance of
syntax classes and rules for multi or single valued
attributes)
- Attribute syntax (e.g. maintenance and support for
attribute value testing and matching, to specification
for a defined set of attribute types)
o Operations
- all operations
- correct function
- correct result
- correct responses
o Aliases (e.g., correct resolution, error responses)
o Authentication and Access Control (e.g., limitation of
modify access)
o ROSE (e.g., correct handling of invokes, results, rejects,
and invoke ids)
o ACSE (e.g., association establishment / refusal for invalid
application contexts, etc.)
8.17.2 Search Operation
Testing of support for filter items should be reasonable. It is
not expected that DSAs will be able to handle worst case testing
in this area.
8.18 Errors
This section provides clarification of the semantics of various
operation errors and implementation guidelines on their usage.
8.18.1 Permanent vs. Temporary Service Errors
The usage of the Service Errors busy, unavailable and
unwillingToPerform requires some clarification:
The error busy is particularly transient. It is returned when
one or more of the Directory's internal resources are being used
to their capacity and, hence, the requested operation cannot, for
the moment, be performed. The Directory should be able to
recover from this type of resource depletion after a short while.
The error unavailable is also temporary but somewhat less
transient. It indicates that the Directory (or some part of it)
is currently unavailable and may continue to be unavailable for
a reasonably long period of time. for example, this error is
returned when a given DSA is functionally disabled, or when a
specific part of the DIB is undergoing reconfiguration.
The error unwillingToPerform has a permanent connotation. It
indicates that the Directory cannot perform the requested
operation because it would require resources beyond its capacity.
For example, this error may be returned by a DSA if, satisfying a
requested would result in the generation of an APDU in excess of
32767 octets.
8.19 APPENDIX A Definitions
Any definitions not found in this appendix can be found in the
Directory Documents.
o Holding
o Propagating
o Centralized
o Cooperating
8.20 APPENDIX B Attributes and Object Classes
The Contents of this section are incomplete. Additional work
describing algorithms related to schemas and special attribute types
should be placed here.
The attribute types defined in the Directory documents, Part 6, and
listed in table 8.1 have requirements for underlying algorithms which
relate:
1. To the checking of attribute values from the viewpoint of
syntactical correctness and compliance with pragmatic
constraints.
2. To the comparison of attribute values for the purpose of
comparison (for equality, for matching substrings, and as a
preliminary for determining relative ordering)
Sections B.1 and B.2 give brief characteristics of the checking and
comparison algorithms, respectively. These characteristics are not
currently defined explicitly in the Directory documents. Section B.3
summarizes their applicability to the attribute syntaxes defined by
the Directory documents.
It should be noted that determining relative ordering requires the
application of a further algorithm appropriate to the type of value
which requires ordering.
B.1 Checking Algorithms
Note. A particular attribute type in some cases defines more than one
alternative attribute syntax. In this case, an attribute value is
satisfied if it satisfies at least one checking algorithm, as listed
below; maximum and minimum sizes may be specified for the attribute-
syntax or the attribute type.
B.1.1 T.61 String Check
Checks that the value has the type code for T.61 string, that it
encodes a sequence of valid T.61 characters, and that it complies with
a maximum character length, if this is specified. Only graphic
characters (including spaces) are permitted.
B.1.2 Printable String Check
Checks that the value has the type code for Printable String, and that
it encodes as a sequence of valid printable string characters, and
that it complies with a maximum character length, if this is
specified.
B.1.3 Numeric String Check
Checks that the value has the type code for numeric string, that it
encodes a sequence of valid numeric string characters, and that it
complies with a maximum character length, if this is specified.
B.1.4 Distinguished Name Check
Checks that the value is a valid ASN.1 encoding for Distinguished
name, and that for each known attribute type (i.e. that is registered
in the DSA) each attribute value satisfies the appropriate checking
algorithm.
B.1.5 Object Identifier Check
Checks that the type is correct. It is further study whether the
value itself can be validated further.
B.1.6 Criteria Check
Checks that the value is a valid ASN.1 encoding for Criteria. It is
for further study whether the value itself can be validated further.
B.1.7 Presentation Address Check
Checks that the value is a valid ASN.1 encoding for Presentation
Address, and that each field is within the size limits appropriate to
the field.
B.1.8 Telephone Number Check
For further study.
B.1.9 Telex Number Check
For further study.
B.1.10 Facsimile Telephone Number Check
Checks that the value of the first element is a valid telephone number
(B.1.8), and that the second element is a valid ASN.1 encoding for
Facsimile G3 Non-Basic Parameters.
B.1.11 Teletex Terminal Identifier Check
Checks that the value of the first element is a valid Printable String
(B.1.2), and that the second element is a valid ASN.1 encoding for
Teletex Non-Basic Parameters.
B.1.12 Integer Check
Checks that the value has integer type, and lies between defined or
default integer values.
B.1.13 String List Check
Checks that each component is compliant using T.61 String Check or
Printable String Check.
B.1.14 Preferred Delivery Method Check
For further study.
B.1.15 Octet String Check
No checking.
B.1.16 Country Check
Checks that the value is a 2-character string complaint with IS 3166
codes only.
B.2 Matching Algorithms
Note: Matching algorithms are conveniently defined in terms of a
two step process.
1. Take the checked reference value and the value to be matched, and
reduce them to a canonical (i.e. standard) form (normalization),
if necessary.
2. Carry out the comparison in the specified way (e.g. equality,
substrings or ordering)
Important Note
The brief descriptions below outline the first step. The algorithms
may be replaced, in a particular implementation, by equivalent
procedures.
B.2.1 String Match
All the specific algorithms below carry out the following basic
normalization: remove leading and trailing spaces; intermediate
multiple spaces become single spaces. For example
"[sp]Time[sp][sp]Flies[sp][sp]" becomes "Time[sp]Flies".
B.2.2 Case Ignore String Match
The basic normalization just described is carried out; in addition
each lower case letter is converted to its upper case form. The ASN.1
value is compared octet by octet, disregarding type. It is possible
in this way to compare, for example, T.61 strings with Printable
Strings.
B.2.3 Case Exact String Match
As above, but without the lower case to upper case conversion.
B.2.4 ASN.1 Match
The ASN.1 is converted to a standardized encoding forms, such as that
given in Part 8 of the Directory documents, section 8.6.
Two ASN.1 values may then be compared octet by octet, including the
initial ASN.1 type. No matching for substrings or order is possible.
B.2.5 Distinguished Name Match
As for ASN.1 match, except that for each AVA within the distinguished
name, normalization takes place (possibly recursively) in accordance
with the nature of the attribute type.
B.2.6 Case Ignore List Match
Each component must match as for Case Ignore String Match.
B.2.7 Criteria Match
For further study.
B.2.8 Telephone Number Match
For further study.
B.2.9 Telex Number Match
For further study.
B.3 Mapping of Attribute Syntaxes
The following table maps the attribute syntaxes of Part 6 of the
Directory documents, to the algorithms described in B.1 and B.2 :
Syntax 3Check 3Match
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
3 3
undefined 3None 3None
caseExactStringSyntax 3T.61 String Check or 3Case Exact String Match
3Printable String Check 3
caseIgnoreStringSyntax 3T.61 String Check or 3Case Ignore String Match
3Printable String Check 3
caseIgnoreListSyntax 3String List Check 3Case Ignore List Match
numericStringSyntax 3Numeric String Check 3Case Exact String Match
printableStringSyntax 3Printable String Check 3Case Exact String Match
distinguishedNameSyntax 3Distinguished Name Check 3Distinguished Name Match
objectIdentifierSyntax 3Object Identifier Check 3No normalization
criteriaSyntax 3Criteria Check 3Criteria Match
presentationAddressSyntax 3Presentation Address Check3Presentation Address Match
telephoneNumberSyntax 3Telephone Number Check 3Telephone Number Match
telexNumberSyntax 3Telex Number Check 3Telex Number Match
countrySyntax 3Country Check 3Case Ignore String Match
integerSyntax 3Integer Check 3No normalization
octetStringSyntax 3Octet String Check 3No normalization
3 3
8.21 APPENDIX C The Use of ROSE
The use of ROSE by the BIND and UNBIND macros as described in the
Directory documents, part 5, clause 8.2 will be used with no
additional agreements.
8.22 APPENDIX D Guidelines
The following guidelines were used to provide a general mechanism for
arriving at pragmatic constraints within the Directory. These are
included for the reader's information.
1. Align with other activities
2. Catch outlandish behavior
o Infinite Loops
o Runaway Process
3. Conserve Resources and Promote Efficiency
o Memory
o CPU
o Bandwidth
o Effort
4. Compromise Arbitrary Opinions
5. Police Actions / Catch Violators
o Protect the Network
6. Facilitate Interworking
7. Syntax Interpretation
o Errors
8. Set practical limits for the purpose of testing 8.23 APPENDIX EGlossary
The following abbreviations may be useful; not all are used within
these agreements.
ACL Access Control List
ACSE Association Control Service Element
ADDMD Administration Directory Management Domain
AETitle Application Entity Title
APDU Application Protocol Data Unit
ASE Application Service Element
ASN.1 Abstract Syntax Notation - 1
AVA Attribute Value Assertion
B-RM Basic Reference Model
CA Certification Authority
CCITT Consultative Committee on International Telegraph &
Telephone
CEN Committee for European Normalization
CENELEC Committee for European Normalization Electronique
CEPT Committee European Postal & Telephonique
COS Corporation for Open Systems
DAP Directory Access Protocol
DIB Directory Information Base
DIT Directory Information Tree
DMD Directory Management Domains
DSA Directory System Agent
DSP Directory System Protocol
DUA Directory User Agent
EWOS European Workshop for Open Systems
FTAM File Transfer, Access & Management
INTAP Interoperability Technical Association for Information
Processing, Japan
ISDN Integrated Services Digital Network
ISO International Organization for Standardization
KT Knowledge Tree
LL Lower layers of OSI model (layers 1-4)
MAP Manufacturing Automation Protocol
MHS Message Handling Systems
NBS National Bureau of Standards
NSAP Network Services Access Point
OSI Open Systems Interconnection
PKCS Public Key Crypto System
POSI Promotion for Open System Interconnection
PRDMD Private Directory Management Domain
PSAP Presentation Service Access Point
RDN Relative Distinguished Name
ROSE Remote Operations Service Element
SIG Special Interest Group
SPAG Standards Promotion & Application Group
TOP Technical and Office Protocols
UL Upper layers of OSI model (layers 5-7)
UPU Universal Postal Union
9. SECURITY
The Security Architecture specified in ISO 7498/Part 2 - Security
Architecture (as presented in ISO/TC 97/SC 21/N1528) shall be used as a
basis for further work in the Special Interest Group on Security.
The security services that are to be implemented first shall include
confidentiality, integrity, authentication and access control. Non-
repudiation of the source shall also be included for consideration for
implementation. These services are defined and discussed in more detail
in ISO 7498/Part 2 - Security Architecture.
9.1 Definitions
The following definitions, based on the definitions in ISO 7498/Part2,
are to be used when interpreting Chapter 9.
Access Control: The provision of a security system
that establishes and enforces which
users or processes can get access
to what data or processing
facilities.
Authentication
Information: Information used to establish the
validity of a claimed identity.
Authorization: The granting of access rights.
Confidentiality: A security service that protects
data from unauthorized disclosure.
Connection: A state of communication that
exists between two communicating
entities by establishing an
association between them, providing
one or more data paths between them
allowing sequential transfers of
data, and then terminating the
association.
Connectionless: A state of communication that
provides transfer of data from one
entity to another without a
preestablished association.
Data Integrity: The property that data has not been
altered or destroyed in an
unauthorized manner.
Data Origin
Authentication: The corroboration that the source
of data received is as claimed.
Digital Signature: Data that allows a recipient of
information to verify the source
and integrity of the information.
Peer-entity
Authentication: The corroboration that peer
entities in an association are as
claimed.
Repudiation: Denial by one or both of the
entities of an association of
having participated in all or part
of the association or
communication of the association.
Selective Field
Protection: The protection of specified fields
of data in a communication.
Traffic Analysis: The inference of information from
observation of traffic flow in
communications (presence, absence,
amount, direction and frequency).
Traffic Flow
Confidentiality: A confidentiality service to
protect against traffic analysis.
9.2 Matrix of Security Services and OSI Layers
The following matrix shows the layers of the OSI architecture at which
certain security services are considered to be desirable. The entries
in the matrix are "H" for high level of desirability, "M" for medium
desirability, and "L" for low level of desirability. No entry in the
matrix means that the service is not considered desirable. This
matrix was produced from a similar matrix in ISO 7498/Part 2 which
showed the layers of the architecture that could be used to provide
the security service. The level of desirability was established by
the members of the Special Interest Group in Security of the OSI
Implementors Workshop.
Note: The Matrix is a consensus of the opinions of the members as to
where selected security services should be placed. It should not be
considered restrictive and interpreted as meaning that the security
services cannot be placed elsewhere in the OSI architecture or have
other implementation priorities. This will depend upon the differing
security needs of specific applications. Also, it should not be
considered complete in that other security services may exist that
should be incorporated in the architecture.
Table 9.1 OSI Layers Desirable for Placing Security
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDBDDDBDDDBDDDBDDDBDDDBDDDBDDD?
3 SERVICE 3 1 3 2 3 3 3 4 3 5 3 6 3 7 3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEDDDEDDDEDDDEDDDEDDDEDDDEDDD4
3 3 3 3 3 3 3 3 3
31.(a) Peer entity authentication 3 3 3 L 3 H 3 3 3 H 3
3 (b) Data origin authentication 3 3 3 L 3 L 3 3 3 H 3
3 3 3 3 3 3 3 3 3
32. Access Control Service 3 Authorization Model 3 3
3 3 3 3 3 3 3 3 3
33.(a) Connection confidentiality 3 L 3 L 3 L 3 H 3 3 H 3 H 3
3 (b) Connectionless confidentiality 3 3 L 3 H 3 L 3 3 H 3 H 3
3 (c) Selective field confidentiality 3 3 3 3 3 3 H 3 H 3
3 (d) Traffic flow confidentiality 3 M 3 3 L 3 3 3 3 L 3
3 3 3 3 3 3 3 3 3
34.(a) Connection integrity with recovery 3 3 3 3 H 3 3 3 L 3
3 (b) Connection integrity without recovery 3 3 3 No Plan 3 3 3
3 (c) Selective field connection integrity 3 3 3 No Plan 3 3 3
3 (d) Connectionless integrity 3 3 3 H 3 L 3 3 3 L 3
3 (e) Selective field connectionless integrity3 3 3 3 3 3 3 H 3
3 3 3 3 3 3 3 3 3
35.(a) Non-repudiation: originator 3 3 3 3 3 3 3 L 3
3 (b) Non-repudiation: receiver 3 3 3 3 3 3 3 L 3
3 3 3 3 3 3 3 3 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDADDDADDDADDDADDDADDDADDDADDDY
Implementation priority: H (high)
M (medium)
L (Low)
Table 1 ISO 7498/Part 2: Security Addendum -- NBS OSI Workshop
Summary Of SIG-SEC Discussions of Security Service Placement, May,
1987
Notes: The following notes are for explanation of the above matrix and
comments.
A security system should be considered to be an integrated set of
security services that are placed at selected OSI layers. The
services should be selected based on a risk analysis for the computer
system being protected. Security mechanisms must be then chosen that
will provide the security services and incorporated in the software
and hardware of the computer system and controlled by the OSI software
and hardware at the selected layer(s).
For example, authentication, access control, confidentiality and
integrity are selected as the major security goals for an OSI system.
A connection oriented transport protocol is being implemented. An
example of the use of the Matrix could be in an electronic mail
system, to illustrate this the following specific services and layers
were chosen:
Peer entity authentication: Layer 4
Data origin authentication: Layer 7
Access Control: Layer 7
Connection confidentiality: Layer 4
Selective field confidentiality: Layer 7
Connection integrity with recovery: Layer 4
Connectionless integrity: Layer 7
The layer 7 services were chosen to support the mail system that would
protect the selective paragraphs of an electronic message as directed
by the user. A mail system is considered connectionless. Access
control is a function of only layer 7.
The layer 4 services were chosen to provide a reliable transport
service from the sender to the intended receive of the electronic
message. A full connection integrity and confidentiality service with
peer entity authentication will assure that all information gets to
the receiver correctly and confidentially.
Note: The security protocols and mechanisms that provide these
services are beyond the scope of this Chapter at this time. The
mechanisms and standards for their interoperability are presently
being defined and will be added to this Chapter as they become
available.
11. REFERENCES
Selected references are grouped by organization publishing the documents
and by Reference Model layer to aid relating standards to the OSI Basic
Reference Model and to aid relating equivalent standards published by
different standards organizations.
10. OBJECT IDENTIFIER: STRUCTURE AND ALLOCATION
In order to complete a stable version of the NBS OSI Implementation
Agreements, the following objects need to be administered by an ad
hoc registration authority:
Application Context Name
Abstract Syntax Name
Transfer Syntax Name
Document Type Name
Constraint Set Name
File Model
Since all objects to be administered by the NBS Workshop SIGs are
identified by the ASN.1 type OBJECT IDENTIFIER, the following
structure shall be used:
Using the NameAndNumberForm (::= identifier (NumberForm) ) for an
ObjIdComponent we have:
ObjectIdentifierValue ::= { identifier1 (NumberForm1)
identifier2 (NumberForm2)
identifier3 (NumberForm3)
identifier4 (NumberForm4)
identifier5 (NumberForm5)
identifier6 (NumberForm6) }
The assignment of identifiers and NumberForms is as follows:
identifier1 NumberForm1
iso 1
identifier2 NumberForm2
identified-organization 3
identifier3 NumberForm3
issuing-organization 9999
identifier4 NumberForm4
organization-code 1
identifier5 NumberForm5
application-context 1
abstract-syntax 2
file model 3
constraint-set 4
document-type 5
transfer-syntax 6
ftam-nil-ap-title 7
Note 1: The value of NumberForm3 is selected for use by implementors
of these agreements: it has not been assigned by ISO or by
any official Registration Authority. It does correspond to
an "ad hoc" issuing organization with an ICD of 9999, as
specified by ISO 6523. We intend to use the procedure
designated in D.7 of the Specification of ASN.1, ISO 8824
once the appropriate Registration Authority has been
established. This mechanism is subject to change dependent
upon ISO standards.
Note 2: Specific values for identifier6 and NumberForm6 are chosen
as needed by the . A table of the currently allocated
values is given later.
Note 3: The NBS UL SIG will assign values for identifier5 and
NumberForm5 as required by other SIGs.
Note 4: Companies wishing to interoperate may designate themselves
with an organization code other than 1 under
{ iso (1) identified-organization (3) -
issuing-organization (9999) } for the purpose of defining
private OBJECT IDENTIFIERs.
Table 10.1 TABLE OF ALLOCATED OBJECT IDENTIFIERS
The values of the first 4 NumberForms are constant, so the following
value is defined for use in the table below.
nbs-ad-hoc OBJECT IDENTIFIER ::= {1 3 9999 1}
Note that the only OBJECT IDENTIFIERS herein defined all begin with "nbs-
ad-hoc"; all other OBJECT IDENTIFIERS and their associated
ObjeceDescriptor's are reproduced here solely for the convenience of
implementors. The standards defining these OBJECT IDENTIFIERSs and
ObjectDescriptor's take precedence over the values specified below.
Application Context
"ISO FTAM"
{ iso (1) standard (0) 8571 application-context (1) iso-ftam (1)
}
Abstract Syntax
"FTAM PCI"
{ iso (1) standard (0) 8571 abstract-syntax (2) ftam-pci (1) }
"FTAM FADU"
{ iso (1) standard (0) 8571 abstract-syntax (2) ftam-fadu (2) }
"FTAM unstructured text abstract syntax"
{ iso (1) standard (0) 8571 abstract-syntax (2) unstructured-text
(3) }
"FTAM unstructured binary abstract syntax"
{ iso (1) standard (0) 8571 abstract-syntax (2) unstructured-
binary (4) }
"NBS abstract syntax AS1"
{ nbs-ad-hoc abstract-syntax (2) nbs-as1 (1) }
"NBS file directory entry abstract syntax"
{ nbs-ad-hoc abstract-syntax (2) nbs-as2 (2) }
"ISO 8650-ACSE1"
{ joint-iso-ccitt association-control (2) abstract-syntax (1)
apdus (0) version1 (1) }
"Directory Services"
File Model
"FTAM hierarchical file model"
{ iso (1) standard (0) 8571 file-model (3) hierarchical (1) }
Constraint Set
"FTAM unstructured constraint set"
{ iso (1) standard (0) 8571 constraint-set (4) unstructured (1) }
"FTAM sequential flat constraint set"
{ iso (1) standard (0) 8571 constraint-set (4) sequential-flat
(2) }
"FTAM ordered flat constraint set"
{ iso (1) standard (0) 8571 constraint-set (4) ordered-flat (3) }
"NBS ordered flat constraint set"
{ nbs-ad-hoc constraint-set (4) nbs_ordered-flat (3) }
Document Type
"ISO FTAM unstructured text"
{ iso (1) standard (0) 8571 document-type (5) unstructured-text
(1) }
"ISO FTAM sequential text"
{ iso (1) standard (0) 8571 document-type (5) sequential-text (2)
}
"ISO FTAM unstructured binary"
{ iso (1) standard (0) 8571 document-type (5) unstructured-binary
(3) }
"NBS-6 FTAM sequential file"
{ nbs-ad-hoc document-type (5) sequential (6) }
"NBS-7 FTAM random access file"
{ nbs-ad-hoc document-type (5) random-file (7) }
"NBS-8 FTAM indexed file"
{ nbs-ad-hoc document-type (5) indexed-file (8) }
"NBS-9 FTAM file directory file"
{ nbs-ad-hoc document-type (5) file-directory (9) }
Transfer Syntax
" Basic Encoding of a single ASN.1 type"
{ joint-iso-ccitt (2) asn1 (1) basic-encoding (1) }
Miscellaneous
"nil AP Title"
{ nbs-ad-hoc ftam-nil-ap-title (7) }
10.1 Specific ASE Requirements for ACSE Presentation and Session
The following list for each ASE the corresponding NBS SIGs
requirements of and restrictions on ACSE, Presentation, and Session.
All listed requirements and restrictions shall be included in an NBS
conformant system and shall be implemented in accordance with these
NBS Implementor's agreements.
All OBJECT IDENTIFIERS are specified in terms of their associated
ObjectDescriptor's. See the chapter on OBJECT IDENTIFIERs for the
values of the associated OBJECT IDENTIFIERs.
10.1.1 FTAM
10.1.1.1 Phase 2
ACSE Requirements:
all
Application Contexts:
o "ISO FTAM" - implies the use of the
ACSE and the FTAM ASE.
Abstract Syntaxes:
o "ISO 8650-ACSE1"
Associated Transfer Syntax:
o "Basic Encoding of a
single ASN.1 type"
Presentation Requirements:
Presentation Functional Units:
o kernel
Presentation Contexts:
o At least 4 Presentation Contexts
must be supported.
Abstract Syntaxes:
o "FTAM-PCI"
Associated Transfer Syntax:
o "Basic Encoding of a
single ASN.1 type:
o "FTAM-FADU"
Associated Transfer Syntax:
o "Basic Encoding of a
single ASN.1 type"
o "FTAM unstructured text abstract
syntax"
Associated Transfer Syntax:
o "Basic Encoding of a
single ASN.1 type"
o "FTAM unstructured binary abstract
syntax"
Associated Transfer Syntax:
o "Basic Encoding of a
single Asn.1 type"
o "NBS abstract syntax AS1"
Associated Transfer Syntax:
o "Basic Encoding of a
single ASN.1 type"
o "NBS file directory entry abstract
syntax"
Associated Transfer Syntax:
o "Basic Encoding of a
single Asn.1 type"
o "NBS file directory entry abstract
syntax"
Associated Transfer Syntax:
o "Basic Encoding of a
single Asn.1 type"
Session Requirements:
Session Functional Units:
o kernel
o duplex
Version Number: 2
Maximum size of User Data parameter field:
10,240
Session Options:
Session Functional Units:
o resynchronize
only a Resynchronize Type
value of "abandon"
o minor synchronize
Note: The minor
synchronize
functional unit is
required whenever
the resynchronize
functional unit is
available.
10.1.2 MHS
10.1.2.1 Phase 1
Session Requirements:
Session Functional Units:
o kernel
o half-duplex
o exceptions
o activity management
o minor synchronize
Version Number: 1
Maximum size of User Data parameter field:
512
Session Notes:
o Restricted use is made by the RTS
of the session services implied by
the functional units selected.
Specifically,
. No use is made of S-TOKEN-
GIVE, and
. S-PLEASE-TOKENS only asks for
the data token.
o In the S-CONNECT SPDU, the Initial
Serial Number should not be
present.
o The format of the Connection
Identifier in the S-CONNECT SPDU is
described in Version 5 of the
X.400-Series Implementors' Guide.
10.1.3 DS
10.1.3.1 Phase 1
ACSE Requirements:
all
Application Context:
Abstract Syntaxes:
o "ISO 8650-ACSE1"
Associated Transfer Syntax:
o "Basic Encoding of a
single ASN.1 type"
o "Directory Services"
Associated Transfer Syntax:
o "Basic Encoding of a
single ASN.1 type"
Presentation Requirements:
Presentation Functional Units:
o kernel
Presentation Contexts:
o At least 2 Presentation Contexts
must be supported.
Session Requirements:
Session Functional Units
o kernel
o duplex
Version Number:2
Maximum size of User Data parameter field:
10,240
11.1 CCITT
Network Layer
CCITT Recommendation X.25 - 1980, Interface Between Data Terminal
Equipment (DTE) and Data Circuit-Terminating Equipment (DCE) for
Terminals Operating in the Packet Mode on Public Data Networks.
CCITT Recommendation X.25 - 1984, Interface Between Data Terminal
Equipment (DTE) and Data Circuit-Terminating Equipment (DCE) for
Terminals Operating in the Packet Mode on Public Data Networks.
Transport Layer
CCITT Recommendation X.214, (Red Book, 1984), Transport Service
Definition for Open Systems Interconnection for CCITT Applications.
CCITT Recommendation X.224, (Red Book, 1984), Transport Protocol Profile
for Open Systems Interconnection for CCITT Applications.
Session Layer
CCITT Recommendation X.215, (Red Book, 1984), Session Service Definition
for Open Systems Interconnection for CCITT Applications.
CCITT Recommendation X.225, (Red Book, 1984), Session Protocol Profile
for Open Systems Interconnection for CCITT Applications.
Presentation
CCITT Recommendation T.50, (Red Book, 1984), International Alphabet No.
5.
Application Layer -- MHS
CCITT Recommendation X.400, (Red Book, 1984), Message Handling Systems:
System Model-Service Elements.
CCITT Recommendation X.401, (Red Book, 1984), Message Handling Systems:
Basic Service Elements and Optional User Facilities.
CCITT Recommendation X.408, (Red Book, 1984), Message Handling Systems:
Encoded Information Type Conversion Rules.
CCITT Recommendation X.409, (Red Book, 1984), Message Handling Systems:
Presentation Transfer Syntax and Notation.
CCITT Recommendation X.410, (Red Book, 1984), Message Handling Systems:
Remote Operations and Reliable Transfer Server.
CCITT Recommendation X.411, (Red Book, 1984), Message Handling Systems:
Message Transfer Layer.
CCITT Recommendation X.420, (Red Book, 1984), Message
Handling Systems: Interpersonal Messaging User Agent Layer.
CCITT Recommendation X.430, (Red Book, 1984), Message Handling Systems:
Access Protocol for Teletex Terminals.
11.2 ISO
Status of ISO work can be determined by the reference number; working
drafts are referenced by committee and number; e.g., TC 97/SC 6 Nxxxx.
Standards are cited by either ISO xxxx or IS xxxx; DIS and DPs are cited
in similar form. Note: ISO TC 97 is now called ISO/IEC JTC1.
Information Processing Systems - Open Systems Interconnection - Basic
Reference Model. ISO/IS 7498. First Edition - Oct. 15, 1984. Ref. No.
ISO 7498-1984(E).
OSI Basic Reference Model - Part 2: Security Architecture. ISO/DIS
7498-2 TC 97/SC 21/N1895. Project 97.21.18. May 1987.
OSI Basic Reference Model - Part 3: Naming and Addressing. ISO/DIS 7498-
3, ISO/TC 97/ SC 21 N2141. May, 1987.
Data Interchange - Structure for the identification of organizations.
ISO 6523. 1984-02-01.
Physical Layer
Information Processing Systems - Local Area Networks - Part 3: Carrier
Sense Multiple Access with Collision Detection (CSMA/CD) and Physical
Layer Specification ISO/DIS 8802/3
Information Processing Systems - Local Area Networks - Part 4:
Token-Passing Bus Access Method and Physical Layer Specification,
ISO/DIS 8802/4
Information Processing Systems - Local Area Networks - Part 5: Token-Ring
Access Method and Physical Layer Specification ISO/DIS 8802/5
ISO 8802-5 Final Text of ISO/DIS 8802-5: Info proc systems - Local Area
Nets -Part 5: Token ring access method and physical layer specification,
ISO/TC 97/SC 6 N4477,1987
Data Link Layer
Information Processing Systems - Local Area Networks - Part 2: Logical
Link Control ISO/DIS 8802/2 1985
ISO 8802-2 Text for ISO/DIS 8802-2.2, Logical Link Control, ISO/TC 97/SC
6 N4609, 1987
Information Processing Systems - Data Communications - High-Level Data
Link Control Procedures - Description of the X.25 LAPB-compatible DTE
Data Link Procedures, IS 7776.
Network Layer
Information Processing Systems - Open Systems Interconnection - Network
Service Definition, IS 8348.
Information Processing Systems - Open Systems Interconnection - Addendum
to the Network Service Definition Covering Connectionless Data
Transmission, IS 8348/AD1.
Information Processing Systems - Open Systems Interconnection - Addendum
to the Network Service Definition Covering Network Layer Addressing,
IS 8348/AD2.
Information Processing Systems - Open Systems Interconnection - Internal
Organization of the Network Layer, DIS 8648.
Information Processing Systems - Open Systems Interconnection - Protocol
for Providing the Connectionless Network Service, IS 8473.
Information Processing Systems - Open Systems Interconnection -Addendumto
IS 8473 - Provision of the Underlying Service Assumed by ISO 8473, ISO TC
97/SC 6 N 3453.
Information Processing Systems - Open Systems Interconnection, Working
Draft, End System to Intermediate System Routing Exchange Protocol for
use in Conjunction with ISO 8473 ISO/DIS 9542 TC 97/SC 6 N 4053.
Information Processing Systems - Open Systems Interconnection - Data
Communications - X.25 Packet Level Protocol for Data Terminal Equipment,
IS 8208.
Information Processing Systems - Open Systems Interconnection - Data
Communications - Use of X.25 to provide the OSI Connection-mode Network
Service DIS 8878
Transport Layer
Information Processing Systems - Open Systems Interconnection - Transport
Service Definition, IS 8072.
Information Processing Systems - Open Systems Interconnection - Transport
Protocol Specification, IS 8072, 1984.
Session Layer
Information Processing Systems - Open Systems Interconnection - Basic
Connection Oriented Session Service Definition, ISO 8326: 1987 (E).
Information Processing Systems - Open Systems Interconnection - Basic
Connection Oriented Session Protocol Specification, ISO 8327 8326: 1987
(E).
Information Processing Systems - OSI - Basic Oriented Session Service
Definition - DAD 2 to ISO 8326 to Incorporate Unlimited User Data,
ISO/IS 8326. Aug. 27, 1987.
Information Processing Systems - OSI - Basic Oriented Session Protocol
Specification - DAD 2 to ISO 8327 to Incorporate Unlimited User Data,
ISO/IS 8327. Aug. 27, 1987.
Information Processing Systems - Open Systems Interconnection - Basic
Connection Oriented Session Service Definition-AD 2 to ISO 8326 to
Incorporate Unlimited User Data, ISO/IEC JTC1/SC21 N2494.
Information Processing Systems - Open Systems Interconnection - Basic
Connection Oriented Session Protocol Specification - AD 2 to ISO 8327 to
Incorporate Unlimited User Data, ISO/IEC JTC1/SC21 N2495.
Note: The Session DAD2 Documents This Document, SC21 1987,
may also be obtained from:
Standards Resource Librarian
AT&T Bell Labs
IM304
Crawfords Corner Rd.
Holmdel, NJ
07733
Presentation Layer
Information Processing Systems - Open Systems Interconnection -
Connection-Oriented Presentation Service Definition, ISO 8822: 1987 (E),
(ISO/TC97/SC21 N 2335). Note: until final text is available, reference
Proof G.
Information Processing Systems - Open Systems Interconnection -
Connection Oriented Presentation Protocol Specification, ISO 8823: 1987
(E), (ISO/TC97/SC21 N 2336). Note: until final text is available,
reference Proof G.
Information Processing Systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1), ISO 8824: 1987
(E).
Information Processing Systems - Open Systems Interconnection -
Specification of Basic Encoding Rules for Abstract Syntax Notation
(ASN.1), ISO 8825: 1987 (E).
7-bit Coded Character Set for Information Processing Interchange, ISO
646.
Information Interchange - Representation of Local Time Differentials,
ISO 3307.
Application Layer
Information Processing Systems - Open Systems Interconnection -
Application Layer Structure, ISO/DP 9545, ISO/TC97/SC21/N1743. July 24,
1987. Revised November 1987.
Application Layer -- FTAM
Information Processing Systems - Open Systems Interconnection - File
Transfer, Access and Management Part I: General Introduction, ISO 8571-1:
1987 (E) (ISO/TC97/SC21 N 2331).
Information Processing Systems - Open Systems Interconnection - File
Transfer, Access and Management Part 2: Virtual Filestore Definition, ISO
8571-2: 1987 (E) (ISO/TC97/SC21 N 2332).
Information Processing Systems - Open Systems Interconnection - File
Transfer, Access and Management Part 3: The File Service Definition, ISO
8571-3: 1987 (E) (ISO/TC97/SC21 N 2333).
Information Processing Systems - Open Systems Interconnection - File
Transfer, Access and Management Part 4: File Protocol Specification, ISO
8571-4: 1987 (E) (ISO/TC97/SC21 N 2334).
Application Layer -- ASE/ACSE
Information Processing Systems - Open Systems Interconnection - Service
Definition for the Association Control Service Element, ISO 8649: 1987
(E) (ISO/IEC JTC1/SC21 N2326) (ISO/TC97/SC21 N)
Information Processing Systems - Open Systems Interconnection - Protocol
Specification for the Association Control Service Element, ISO 8650:
1987 (E) (ISO/IEC JTC1/SC21 N2327) (ISO/TC97/SC21 N)
Application Layer -- VTP
Information Processing Systems - Open Systems Interconnection - Virtual
Terminal Service - Basic Class, IS 9040.
Information Processing Systems - Open Systems Interconnection - Virtual
Terminal Protocol - Basic Class, IS 9041.
Application Process -- Office Document Interchange -- ODA/ODIF
Information Processing Systems - Text and Office Systems - Office
Document Architecture (ODA) and Interchange Format - Part 1; General
Information, DIS 8613/1.
Information Processing Systems - Text and Office Systems - Office
Document Architecture (ODA) and Interchange Format - Part 2; Document
Structures, DIS 8613/2.
Information Processing Systems - Text and Office Systems - Office
Document Architecture (ODA) and Interchange Format - Part 3; Document
Processing Reference Model, DIS 8613/3.
Information Processing Systems - Text and Office Systems - Office
Document Architecture (ODA) and Interchange Format - Part 4; Document
Profile, DIS 8613/4.
Information Processing Systems - Text and Office Systems - Office
Document Architecture (ODA) and Interchange Format - Part 5; Office
Document Interchange Format, DIS 8613/5.
Information Processing Systems - Text and Office Systems - Office
Document Architecture (ODA) and Interchange Format - Part 6; Character
Content Architecture, DIS 8613/6.
Information Processing Systems - Text and Office Systems - Office
Document Architecture (ODA) and Interchange Format - Part 7; Raster
Graphics Content Architecture, DP 8316/7.
Information Processing Systems - Text and Office Systems - Office
Document Architecture (ODA) and Interchange Format - Part 8; Geometric
Graphics Content Architecture, DP 8613/8.
Information Processing Systems - Text and Office Systems - Standard
Generalized Markup Language (SGML), IS 8879.
Application Process -- Computer Graphics -- CGM/GKS
Information Processing Systems - Computer Graphics - Metafile (CGM) for
the Storage and Transfer of Picture Description Information, Part 1;
Functional Specification, IS 8632/1
Information Processing Systems - Computer Graphics - Metafile (CGM) for
the Storage and Transfer of Picture Description Information, Part 2;
Character Encoding, IS 8632/2
Information Processing Systems - Computer Graphics - Metafile (CGM) for
the Storage and Transfer of Picture Description Information, Part 3;
Binary Encoding, IS 8632/3.
Information Processing Systems - Computer Graphics - Metafile (CGM) for
the Storage and Transfer of Picture Description Information, Part 4;
Clear Text Encoding, IS 8632/4.
Information Processing Systems - Font and Character Information
Interchange, IS 9541.
Information Processing Systems - 8-Bit Single Byte Coded Graphic
Character Sets, Part 1; Latin Alphabet Part 1, IS 8859/1.
Information Processing Systems - Computer Graphics Functional
Specification of the Graphical Kernel System (GKS), IS 7942.
Information Processing Systems - Computer Graphics - Graphical Kernel
System for Three Dimensions (GKS-3D), Functional Description, DIS 8805.
Information Processing Systems - Computer Graphics - Programmers
Hierarchical Interactive Graphics System (PHIGS), DP 9592.
Information Processing Systems - Computer Graphics - Interfacing
Techniques for Dialogues with Graphical Devices (CGI),ISO TC 97/SC 21 N
1179.
Application Layer -- Directory Services
The Directory--Overview of Concepts, Models, and Services (CCITT
Recommendation X.500, ISO 9594)
The Directory--Information Framework (CCITT Recommendation X.501, ISO
9594)
The Directory--Access and System Services Definition (CCITT
Recommendation X.511, ISO 9594)
The Directory--Procedures For Distributed Operation (CCITT
Recommendation X.518, ISO 9594)
The Directory--Access and System Protocols Specification (CCITT
Recommendation X.519, ISO 9594)
The Directory--Selected Attribute Types (CCITT Recommendation X.520, ISO
9594)
The Directory--Selected Object Classes (CCITT Recommendation X.521, ISO
9594)
The Directory--Authentication Framework (CCITT Recommendation X.509, ISO
9594)
Remote Operations-Part 1: Model, Notation and Service Definition (CCITT
Recommendation X.219, ISO 9072 Version 5)
Remote Operations-Part 2: Protocol Specification (CCITT Recommendation
X.229, ISO 9072 Version 5)
Association Control-Service Definition (CCITT Recommendation X217, ISO
8649)
Association Control-Protocol Definition (CCITT Recommendation X.217, ISO
8650)
Note: ISO 9594, 9072 are preferred texts (over the CCITT counterparts)
and are to be taken as of Gloucester, Nov. 1987.
CCITT documents may be obtained from:
International Telecommunications Union
Place des Nations, CH 1211,
Geneva 20 SWITZERLAND
ISO documents may be obtained from:
Frances E. Schrotter
ANSI
ISO TC 97/SC 6 Secretariat
l430 Broadway
New York, NY. 10018
11.3 IEEE
Physical Layer
IEEE Standard for Local Area Networks: Carrier Sense Multiple Access
with Collision Detection (CSMA/CD) and Physical Layer Specification,
ANSI/IEEE Standard 802.3 1985, Institute of Electrical and Electronics
Engineers, 345 East 47th St., New York, NY. 10017, 1985.
IEEE Standard for Local Area Networks: Supplements to Carrier Sense
Multiple Access with Collision Detection (CSMA/CD) Access Method and
Physical Layer Specification ANSI.IEEE Standard 802.3a, b, c, e -1988
Supplement a, MAU and Baseband Medium Specification, Type 10BASE2
(Section 10)
Supplement a, Broadband MAU & Medium Specification, Type 10BROAD36
(Section 11)
Supplement c, Repeater Set and Repeater Unit Specification for Use with
10BASE5 and 10 BASE2 Networks
Supplement e, Physical Signaling, Medium Attachment, and Baseband Medium
Specification, Type 10BASE5
IEEE Standard for Local Area Networks: Token-Passing Bus Access Method
and Physical Layer Specification, ANSI/IEEE Standard 802.4 - 1985, 802.4
Draft 1987, Institute of Electrical and Electronics Engineers, 345 East
47th St., New York, NY. 10017, 1985.
IEEE Standard for Local Area Networks: Token-Ring Access Method,
ANSI/IEEE Standard 802.5-1985 1986, Institute of Electrical and
Electronics Engineers, 345 East 47th St., New York, NY. 10017, 1985.
Data Link Layer
IEEE Standard for Local Area Networks: Logical Link Control, ANSI/IEEE
Standard 802.2 - 1985 1987, Institute of Electrical and Electronics
Engineers, 345 East 47th St., New York, NY. 10017, 1985.
11.4 NBS
Local Area Networks: Baseband Carrier Sense Multiple Access with
Collision Detection Access Method and Physical Layer Profiles and Link
Layer Protocol, FIPS l07, NTIS, U.S. Department of Commerce, 5285 Port
Royal Road, Springfield, VA. 22l6l.
Interface Between Data Terminal Equipment (DTE) and
DataCircuit-Terminating Equipment (DCE) For Operation With
Packet-Switched Data Communications Networks, FIPS l00, NTIS, U.S.
Department of Commerce, 5285 Port Royal Road, Springfield, VA. 22l6l.
Implementation Agreements for Open Systems Interconnection Protocols:
NBS Workshop for Implementors of Open Systems Interconnection, National
Bureau of Standards, NBSIR 86-3385-6, Robert Rosenthal, Editor, Revised
July 1987.
Implementation Agreements Among Participants of OSINET, National Bureau
of Standards, Institute for Computer Sciences and Technology, NBSIR
86-3478, 1987.
U. S. Government Open Systems Interconnection Profile (GOSIP),
National Bureau of Standards, Institute for Computer Sciences and
Technology, 1987.
NBS documents may be obtained from:
NTIS
U.S. Department of Commerce
5285 Port Royal Road
Springfield, VA. 22l6l.
or
National Bureau of Standards
Institute for Computer Sciences and Technology
Gaithersburg, MD. 20899
11.5 MAP
Manufacturing Automation Protocol, General Motors
Corporation,Manufacturing Engineering and Development, Advanced Product
and Manufacturing Engineering Staff (APMES), APMES A/MD-39, GM Technical
Center, Warren, MI. 48090-9040.
11.6 TOP
Technical and Office Protocols Specification Version 3.0, MAP/TOP Users
Group, Attention TOP 3.0 Document. One SME Drive, P.O. Box 930, Dearborn
Mi. 48121.
11.7 CEN/CENELEC
FTAM Draft Functional Standard A/111 (prENV 41 204) Simple File Transfer-
Unstructrued, 1987-12-01.
ENV 41201 "Private Message Handling Systems"
ENV 41202 "Public Message Handling Systems"
11.8 SPAG
FTAM Draft Profile A/112 Positional File Transfer - Flat, 1987-120-7.
FTAM Draft Profile A/122 Positional File Access - Flat, 1987-12-07.
FTAM Draft Profile A/13 File Management, 1987-12-07.
READER RESPONSE FORM
Please retain my name for the next mailing of the NBS/OSI Implementors
Workshop.
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 3
3NAME 3
3 3
3ADDRESS 3
3 3
3 3
3 3
3 3
3 3
3PHONE NO. 3
3 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
Mail this page to: National Bureau of Standards
NBS Workshop for Implementors of OSI
Bldg. 225/B-217
Gaithersburg, MD 20899